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1  EXECUTIVE  SUMMARY 

This  report  represents  the  final  deliverable  of  the  project  titled  Integrated 
Diagnostics  for  Ground  Equipment  (IDGE). 

The  objectives  of  the  study  are: 

•  Review  the  sources  of  Autonomic  Logistics  data, 

-  The  data  requirements 

-  The  timeliness  or  required  “pull”  of  such  data 

-  Its  transmission  means  (in  garrison  and  the  field,  afloat  and  ashore) 
The  availability  of  current  or  planned  logistic  systems  to  receive  the 
data 

-  Decision  Support  Tools  (DSTs)  to  transform  data  into  necessary 
information  by  which  timely  and  long  term  support  decisions  can  be 
made  as  part  of  Total  Ownership  Cost  (TOC) 

•  Recommend  standards  for  the  Corps  to  apply  across  existing  and  planned 
end  items  regarding  diagnostic  sensor  integration 

The  project  charged  the  interdisciplinary  team  from  Penn  State  University  to 
investigate  the  viability  of  implementing  Integrated  Diagnostics  incorporating 
Condition-Based  Maintenance  (CBM)  for  Ground  Equipment  used  by  the  U.  S. 
Marine  Corps.  The  interdisciplinary  team  was  made  up  of  participants  from 
Department  of  Industrial  Engineering  (DolE),  School  of  Information  Sciences  and 
Technology  (SIST)  and  Applied  Research  Lab  (ARL). 

The  study  over  the  past  14  months  has  resulted  in  integration  of  research  from 
multiple  fields,  involved  study  of  industry  practices  in  condition-based 
maintenance,  and  has  sought  and  obtained  participation  from  several  U.  S. 
Marine  Corps  units  including  Maintenance  and  Supply  divisions.  A  number  of 
current  systems  were  also  studied,  specifically  to  understand  their  contribution  to 
integrated  diagnostics,  including  Marine  Corps  Integrated  Management  System 
(MIMMS),  Supported  Activities  Supply  System  (SASSY)  and  Marine  Corps 
Equipment  Readiness  Information  Tool  (MERIT)  as  were  current  maintenance 
and  supply  practices.  Prior  work  leveraged  included  the  Quadrant  Model  as  well 
as  several  studies  related  to  research  streams  (e.g.  data  mining  and  data  fusion) 
that  contributed  to  the  study. 

The  results  of  the  study  are  presented  in  the  final  version  of  this  report  as  a 
collection  of  templates  that  Program  Managers  for  different  items  may  use  for 
initiating  Autonomic  Logistics  and  CBM  for  the  platforms  that  they  are 
responsible  for.  The  templates  that  are  presented  range  from  a  host  of  decisions 
that  include  sensor  selection  /  placement,  identification  of  decision  nodes  and 
support  technologies  including  data  mining  and  data  fusion,  architectural 
decisions  such  as  the  placement  of  data  repositories  at  different  locations,  and 
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current  and  future  practices  that  can  be  uncovered  as  use  cases  and  scenarios 
so  they  exhibit  fidelity  with  current  practices  as  well  as  retain  informal  practices. 

1. 1  Core  Assumptions 

The  work  contained  in  the  report  is  informed  by  a  few  core  assumptions  that  the 
team  made  in  the  early  part  of  the  project  in  collaboration  with  relevant  personnel 
from  the  USMC,  who  participated  in  the  project. 

First,  it  was  assumed  that  a  strategy  for  integrated  diagnostics  would  be  hybrid 
i.e.  a  mix  of  legacy  systems  and  new  applications  that  would  provide  a  migration 
path  for  the  existing  fleet  of  vehicles  or  major  end-items  as  well  as  leverage  the 
investments  in  applications  and  people  that  currently  exist.  In  particular,  this 
meant  that  the  team  used  the  U.S.  Marine  Corps  Operational  Architecture  (OA) 
as  the  backdrop  against  which  it  would  generate  its  recommendations.  Two  other 
strategies  were  considered  and  discarded.  The  strategy  of  requiring  installation 
and  use  of  proprietary  sensor  technology  in  vehicles  that  would  drive  the  IT 
infrastructure  for  CBM  was  considered  too  risky.  The  strategy  of  only  using 
existing  applications  such  as  MIMMS  and  MERIT  was  considered  inadequate  to 
realize  the  innovations  that  would  make  integrated  diagnostics  possible. 

Second,  the  methodology  for  investigating  the  problem  was  informed  by  the  dual, 
top-down  (user-driven)  and  bottom-up  (sensor-driven)  approaches  (see  Figure 
1.1)  that  informed  each  other  and  ensured,  through  an  internal  consistency 
check,  that  the  recommendations  would  be  feasible  (bottom-up)  as  well  as 
pragmatic  (top-down).  Iri  particular,  utilizing  contemporary  research  in  the  areas 
of  sensor  technologies,  data  mining,  data  fusion,  and  condition-based 
maintenance  operationalized  the  bottom-up  approach.  The  top-down  approach 
was  used  to  envision  the  proposed  IDGE  system,  operationalized  by  utilizing 
research  from  scenario-based  analysis  of  systems  and  techniques  such  as  use 
cases.  The  results  were  also  informed  by  prior  work  in  the  areas  of  the  Quadrant 
Model  for  supply  chains  and  industry  practices  related  to  condition-based 
maintenance. 
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Figure  1.1  The  Analysis  Approach 

Figure  1.1  captures  the  essential  processes  that  are  part  of  the  envisioned 
system.  This  includes  a  CBM  system  on  board  the  Light  Armored  Vehicle  (LAV) 
that  identifies  anomalies  during  operations.  The  signals  generated  by  the  sensors 
are  either  processed  on  board  or  transmitted  to  an  external  processing  unit  for 
diagnosis/prognosis.  Through  diagnosis/prognosis  the  requirements  for  parts, 
manpower  and  facilities  are  identified.  The  system  also  allows  a  human-in-the- 
loop  to  do  the  same  if  required.  These  requirements  trigger  the  specific 
maintenance  processes  within  the  OA.  The  information  collected  during  these 
processes  are  stored  and  catalogued  to  maintain  LAV  history,  and  are  analyzed 
to  help  in  decision  support  at  the  tactical,  operational  and  strategic  levels.  The 
study,  thus,  considered  the  full  cycle  of  processes  from  identification  of 
maintenance  requirements  until  its  fulfillment  and  retrograde.  The  pertinent 
issues  identified  during  the  study  and  the  corresponding  recommendations  are 
listed  against  each  task  specified  within  the  task  description. 

Third ,  to  ensure  that  the  study  would  be  tied  to  a  concrete  exemplar,  a  specific 
kind  of  ground  vehicle  was  chosen.  This  was  the  LAV.  The  LAV  already  has  a 
record  of  deployment  in  the  field,  follows  established  patterns  of  maintenance 
routines  and  is  currently  under  a  service  life  extension  program  (SLEP).  These 
required  the  team  to  ensure  that  they  understand  and  incorporate  existing 
systems  and  practices  in  the  work  carried  out  and  the  recommendations 
developed.  Further,  the  LAV  has  been  the  subject  of  other  CBM  efforts  (one  at 
RIT,  another  at  Penn  State,  ARL),  which  informed  the  present  study. 
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Finally,  two  key  considerations  drove  the  efforts  of  the  team.  First  was  the 
mandate  that  the  practices  for  integrated  diagnostics  for  ground  equipment  be 
significantly  similar  for  garrison  and  in-theatre  situations  instead  of  the  current 
divergence  between  the  two.  To  ensure  this,  trips  were  made  to  the  Schoolhouse 
at  the  Aberdeen  Proving  Grounds,  MD,  and  the  Maintenance  Depot  at  Albany, 
GA.  Second  was  the  desire  that  the  study  be  informed  by  ongoing  efforts  in  other 
agencies  within  the  armed  forces  such  as  the  U.S.  Air  Force  and  the  U.S.  Army. 
Expertise  within  the  team,  engaged  with  similar  projects  with  these  agencies, 
ensured  that  the  current  study  was  influenced  by  results  from  these  agencies. 


1.2  Summary  of  Work  Performed 

The  report  represents  the  work  performed  by  the  team  to  address  the  tasks  it 
was  charged  with.  Following  the  rationale  discussed  earlier,  the  approach  used 
by  the  team  was  one  of  a  combination  of  top-down  and  bottom-up  approaches. 
The  tasks  addressed  by  the  team  were  specified  in  the  following  task  description 
(TD): 

Task  1:  Literature  Review 

•  All  pertinent  USMC  logistics  information  on  one  selected  USMC  end  item 

•  Legacy  logistics  support  systems,  current  operating  procedures  and  future 
support  concepts  to  include  Logistics  Modernization  (which  began  under 
the  Integrated  Logistics  Capability  (ILC)  effort)  for  incorporation  on  the 
selected  system 

•  Technologies  that  do  or  could  support  maintenance  diagnostics  for  the 
selected  end  item 

•  Data  processing  technologies  that  do  or  could  support  predictive 
maintenance  actions  and/or  failure  modes  on  the  end  item 

•  Trend  analysis/decision  technologies  that  would  assist  USMC  logistics 
managers  in  initiating/maintaining  end  item  reliability  situational 
awareness 

Task  2:  Maintenance  Data  Implications 

•  Review  what  types  of  maintenance  data  that  is  currently  being  generated, 
the  sources  of  this  data,  means  of  data  generation,  how  the  data  is 
stored/catalogued/reviewed/acted  upon 

•  Review  the  selected  end  item  for  the  types  of  sensors/diagnostic  tools 
needed  to  facilitate  system  diagnostics/failure  analysis 

•  A  recommendation  on  what  data  representation  and  data  recognition  tools 
are  available  to  transform  data  streams  into  useable  information 

Task  3:  Logistics  Systems  Information 

•  Review  the  suitability  of  current  and  future  logistics  systems  to  use  the 
maintenance  information  generated 
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•  Analyze  the  logistic  support  decisions  for  the  selected  USMC  end  item 
and  future  systems 

•  Determine  the  quantity/quality/timeliness  of  information  to  be  used 

•  Review  candidate  decision  tool  technologies  and  recommend  which  are 
most  suitable  for  implementation 

Task  4:  Establish  Universal  Data  Support  Requirements 

•  Identify  data  support  functions  for  multi-sensor  prognostics  integration  for 
the  selected  end  item 

•  Recommend  candidate  web  based  technologies  to  facilitate  multi-sensor 
prognostic  integration  for  the  selected  end  item 

Task  5:  Identify  Critical  Path  and  Risks  for  One  the  Candidate  System 

•  Identify  a  critical  path  for  implementation  of  a  USMC  Autonomic  Logistics 
Support  System  by  FY  2008 

A  significant  outcome  of  these  tasks  was  expected  to  be  templates  that  Program 
Managers  (PM)  of  different  ground  vehicles  may  use  to  initiate  or  implement 
efforts  that  can  support  integrated  diagnostics.  To  address  the  above  TD,  and  to 
specifically  generate  the  expected  outcome,  the  results  are  structured  in  this 
executive  summary  as  the  progression  from  the  users  of  the  envisioned  system 
to  the  underlying  sensors  that  would  need  to  be  placed  on  the  ground  equipment. 
Figure  1.2  below  shows  this  progression  and  the  templates  resulting  from  each 
step  in  the  progression. 


Figure  1.2  Work  Performed  and  Templates  Generated 

The  structure  of  the  report  reflects  this  bias.  Figure  1.3  below  shows  the  mapping 
of  the  work  performed  against  tasks  from  the  TD  and  their  coverage  in  the 
different  chapters. 
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Figure  1.3  Structure  of  the  Report 


The  analysis  performed  in  this  systematic  manner  resulted  in  the  team’s 
recommendation  for  a  futuristic  IDGE  systems  architecture. 

1.3  Recommendations 

The  work  performed  so  far  has  resulted  in  several  templates  that  are  illustrated  in 
the  relevant  chapters  and  compiled  in  the  appendices  at  the  end  of  the  report. 
The  specific  recommendations  that  we  outline,  therefore,  are  tied  to  the  content 
in  these  templates. 

Recommendation  1 

The  templates  provided  in  the  appendices  represent  the  course  of  action  on 
several  fronts  that  PMs  may  follow  for  initiating  Integrated  Diagnostics  for  the 
ground  equipment  they  are  managing.  Some  of  these  templates  provide 
processes  that  the  PMs  may  follow  (e.g.  Creating  Use  Cases),  whereas  others 
represent  an  outline  of  decisions  that  they  may  adapt  (e.g.  Sensor  Selection  and 
Placement). 

Recommendation  2 

While  the  templates  provide  considerable  guidance,  they  contain  actionable 
items  that  are  distilled  from  much  research  that  has  contributed  to  their 
discovery.  An  educated  use  of  these  templates  will  require  tracing  the  elements 
that  resulted  in  these  templates.  This  information  is  available  in  the  interim  and 
final  reports  provided  to  the  Marine  Corps  as  part  of  this  study.  These  templates 
will  be  made  available  to  the  Marine  Corps  as  a  single  electronic,  browsable 
source  for  use  by  the  Program  Managers. 

Recommendation  3 

The  templates  provided  build  on  the  exemplar,  the  LAV,  used  in  this  study.  They 
will  need  to  be  adapted  and  tailored  for  each  platform.  Use  of  the  templates 
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should,  therefore,  involve  participation  from  the  subject  matter  experts  (SMEs), 
who  are  involved  with  the  maintenance  of  the  platform  in  question.  To  ensure  a 
systematic  evolution  of  these  templates,  a  feedback  mechanism  and  procedure 
should  be  implemented  so  that  the  adapted  templates  are  centrally  integrated 
across  the  business  enterprise. 

Recommendation  4 

The  templates  provide  a  desirable  end-state  for  IDGE.  The  vision  provided  by 
these  templates  for  the  implementation  of  the  systems  architecture  will  require 
some  time  and  effort  to  realize.  A  transition  plan  to  incrementally  introduce 
integrated  diagnostics  should,  therefore,  be  considered  by  each  PM.  This  plan 
should  include  which  systems  e.g.  MIMMS,  MERIT  will  continue  to  play  a  role  in 
the  envisioned  system,  and  how  the  roles  of  individuals  and  units  will  change 
upon  introduction  of  the  proposed  system. 
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1.5  Organization  of  the  Report 

Chapter  2  deals  with  Task  1.  Literature  reviewed  is  identified  and  appropriate 
systems  are  discussed.  In  Chapter  3,  maintenance  data  implications  are 
addressed.  Current  maintenance  practices,  current  data  collection,  the  relevant 
sensor  processing  details  along  with  decision  tools  such  as  quad  model  and  data 
mining  are  discussed.  In  Chapter  4,  the  team’s  work  related  the  current  and  the 
OA  based  futuristic  maintenance  processes,  which  are  discussed  through  the 
help  of  several,  use  cases.  Futuristic  scenarios  developed  and  discussed  in 
detail  in  Chapter  4  led  to  the  identification  of  the  data  items  leading  to  the 
development  of  the  required  data  bases  and  decision  tools  for  tactical, 
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operational  and  strategic  levels.  Chapter  5  covers  the  data  support  functions  for 
multi-sensor  prognostics  and  diagnostics  and  the  envisioned  futuristic  systems 
architecture.  Chapter  5  discusses  in  detail  a  web  based  proof-of-concept  IDGE 
system  with  LAV  as  an  end  item.  This  part  of  the  report  is  not  exhaustive  and  the 
work  is  still  on  going  through  other  related  studies.  Chapter  6  deals  with  critical 
paths  and  risks.  This  final  report  builds  on  the  past  Interim  Reports  (IRs),  which 
are  included  as  Appendices  and  summarizes  the  entire  effort.  A  concise 
summary  is  given  in  each  chapter  for  all  those  tasks  reported  in  the  past  IRs. 
Wherever  appropriate  cross-references  to  the  past  IRs  is  given  those  appendices 
are  included. 
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2  LITERATURE  REVIEW 


Task  1:  Literature  Review  Task  1.1:  Review  all  pertinent  USMC  logistics  information  on 
one  (1)  selected  USMC  end  item.  This  will  include  reviewing  legacy  logistics  support 
systems,  current  operating  procedures  and  future  support  concepts  to  include  the 
Logistics  Modernization  efforts  for  incorporation  on  the  selected  system. 

•  Task  1.2:  Review  of  technologies  that  do  or  could  support  maintenance 
diagnostics  for  the  selected  USMC  equipment. 

o  Task  1.2.1:  Review  of  data  processing  technologies  that  do  or  could 
support  predictive  maintenance  actions  and/or  failure  modes  on  the 
selected  USMC  end  item. 

o  Task  1.2.2:  Review  trend  analysis/decision  technologies  that  would 
assist  USMC  logistics  managers  in  initiating/maintaining  end  item 
reliability  situational  awareness. 

As  a  part  of  the  literature  review,  we  concentrated  on  the  following: 

1.  Autonomic  Logistics 

2.  Current  USMC  maintenance  processes/systems 

3.  Maintenance  systems  in  DoD 

4.  Maintenance  systems  within  commercial  sector 

5.  Sensor  Processing  techniques 

A  brief  summary  of  our  effort  is  reported  in  this  chapter.  Appropriate  details  are 
cross-referenced  with  the  previous  IRs  and  appendices. 

Figure  1.1  shown  in  Chapter  1  represents  the  high-level  conceptual  view  along 
with  the  set  of  processes  for  IDGE.  The  envisioned  system  encompasses  Health 
Monitoring  of  ground  equipment  using  sensors;  A  logistics  system  that  is  capable 
of  autonomously  performing  the  tasks  of  acquiring,  processing  and  distributing 
data;  presentation  of  the  data  in  the  form  of  usable  information  across  the 
enterprise  to  facilitate  efficient  decision  making.  Once  the  team  identified  these 
goals  it  was  necessary  to  scope  the  type  of  literature  that  would  be  reviewed. 
The  team  surveyed  similar  work  done  within  other  DoD  organizations, 
maintenance  systems  used  in  the  Industry  and  the  best  practices  for 
maintenance.  The  team  also  reviewed  the  technical  issues  related  to  sensors, 
sensor  fusion  and  fault  diagnostics.  Each  of  these  issues  was  critically  analyzed 
within  the  context  of  autonomic  logistics. 

The  most  important  driving  force  behind  the  development  of  IDGE  is  the 
Autonomous  Logistics  (AL)  Concept.  The  OA  is  the  foundation  on  which  AL  is 
built.  Therefore  the  team  laid  a  heavy  emphasis  on  OA.  As  OA  covers  the 
operations  related  to  both  the  garrison  and  deployed  environments  the  team 
religiously  followed  the  OA  architecture  for  futuristic  IDGE  system  development. 


The  concept  of  AL  enables  automated  processing  and  distribution  of  data  to 
subsequent  nodes  within  the  system.  Even  though  the  acquisition,  processing 
and  distribution  of  data  are  automated  the  issue  of  visibility  of  the  processes  is 
critical  to  the  Marine  Corps  environment.  Therefore  the  human  in  the  loop  needs 
to  be  supported  with  sufficient  information  and  analysis  for  decision-making.  The 
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idea  of  autonomic  logistics  eliminates  the  need  for  human  effort  in  performing  the 
non-value  added  activities.  MC  personnel  will  be  able  to  utilize  their  time  towards 
making  decisions  and  execution.  This  reduces  the  cognitive  burden  on  the 
personnel.  The  key  enabler  of  the  AL  concept  in  the  context  of  maintenance  is 
information  technology  combined  with  appropriate  sensors  and  fault 
diagnostics/prognostics  techniques. 

The  team  reviewed  the  current  processes  used  for  maintenance  within  the 
USMC  and  observed  the  following  characteristics: 

•  Mission  critical  data  on  weapon  and  support  systems  is  communicated 
from  the  battlefield  through  manual  methods 

•  Reporting  burden  on  the  commander  is  high 

•  Data  is  generally  inaccurate  and/or  lacks  granularity 

•  Data  is  not  timely  -  up  to  24  hours  old 

•  Information  generated,  such  as  Inventory  utilization,  readiness  rate  etc., 
are  not  timely. 

The  high  level  requirements  for  enabling  AL  have  been  identified  as  follows: 

•  Ground  Equipment  that  encompasses  both  diagnostic  and  prognostic 
capability  supported  by  Health  Management  system  onboard 

•  Technical  support  to  the  operational  personnel 

•  An  advanced  Information  System  characterized  by  Wireless 
communication  technology  and  Integrated  Data  Environment  (IDE)  and 
Shared  Data  Environment  (SDE) 

•  A  logistic  infrastructure  that  will  be  responsive  to  support  requirements  of 
the  supported  units  in  near  real-time 

The  team  identified  similar  systems  and  relevant  maintenance  practices  used 
within  the  industry  and  within  DoD.  Critical  analysis  of  these  systems  led  to: 

•  Obtaining  a  better  understanding  about  AL  concept 

•  Understanding  the  latest  technologies  available  for  sensing  and  sensor 
processing 

•  Identifying  the  requirements  of  USMC  maintenance  personnel 

•  Understanding  the  best  maintenance  practices  followed  in  the  Industry 
today 

A  brief  review  of  the  systems  and  technologies  that  were  studied  by  the  team  is 
presented  in  Table  2.1.  The  columns  under  reference  shows  the  Appendix  and 
IR  documents  where  relevant  details  can  be  found. 
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Table  2.1:  System  Review 


System  Review  |  Issues  Identified  |  Reference 

Review  of  the  Existing  Systems  and  Processes 

Current  practices 

-  Most  current  maintenance 
procedures  are  paper  based 

-  The  information  is 
aggregated  and  stored  only 
within  the  supply  units 

-  Limited  analysis  is  performed 
for  decision  support. 

Appendix  8.6:lnterim  Report 

1  (  Paqes  24-31) 

MIMMS 

-MIMMS  is  a  web-based 
system  that  is  used  at  the 
headquarters,  depot  and  for 
field  maintenance. 

-MIMMS  is  a  non  transactional 
database  that  is  used  to  store 
request  information 

Appendix  8.6:  Interim  Report 

1  (Paqes  27-31) 

MERIT 

-The  MERIT  is  a  static  Data 
repository. 

-The  MERIT  system  uses  a 
good  visualization  tool  for 
viewing  the  equipment 
readiness. 

Appendix  8.7:  Interim  Report 

2/3  (Paqes  50-51) 

Global  Combat  Service 
Support-Marine  Corps  (GCSS- 
MC) 

This  is  the  proposed 
integrated  system  that 
presents  enterprise  wide  asset 
visibility 

Appendix  8.6:  Interim  Report 

1  (Paqes  78-87):  (11.3 

Appendix  1:  Paqes  78-89) 

CBM  in  the  Army 

Three  phase  approach 

-  Short  Term  immediate 
insertion  of  sensors  to  acquire 
available  information 

-  Diagnostics,  deploying 
sensors  to  make  automatic 
prediction  about  failures  within 
the  vehicle 

-  Long-term  goal  to  include 
prognostics  module  to  enable 
anticipatory  maintenance. 

Appendix  8.6:lnterim  Report 

1  (Paqes  122 -  124):  (11.7 

Appendix  5:  Paqes  117-132) 

Review  of  Maintenance  Systems  in  the  Industry 

Boeing 

-Boeing  uses  an  effective  web 
based  system 
myboeingfleet.com 
-Boeing  also  uses  a  global 
airline  inventory  network 

Appendix  8.6:  Interim  Report 

1  (Paqes  134-136):  (11.8 

Appendix  6:  Paqes  133-141) 

Penske 

-  Effective  Oil  Analysis 

Program 

-  Six  Sigma  analysis  for 
maintenance  operations 

Appendix  8.6:lnterim  Report 

1  (Paqes  143-147);  (11.9 

Appendix  7:  Paqes  142-148) 
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Automotive  Telematics 
-  GM  OnStar 


Automotive  telematics 
presents  the  key  idea  of 
collecting  health  information  of 
the  vehicle  and  sending  it  to 
do  preventive  maintenance, 

-  Currently  the  sensing 
performed  on  the  vehicle  is 
limited  but  the  OnStar  System 
gives  the  details  of  the 
infrastructure  requirements  to 
facilitate  real-time  health 
monitoring 

-  Location  based  services 

-  Satellite  Communication  to 
relay  real-time  health 
information 


Appendix  8.6:lnterim  Report 

1  (Pages  150 -170):  (11.10 

Appendix  8:  Pages  149-1701 


From  our  survey  we  conclude  that  there  is  no  single  system  that  deals  with 
sensor  information  processing  to  logistics  integration.  Each  of  the  systems 
reviewed  have  their  own  merits  and  shortcomings.  However,  the  relevant 
technologies  identified  have  helped  us  in  detailing  the  IDGE  implementation 
architecture  described  in  Chapter  5. 
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3  MAINTENANCE  DATA  IMPLICATIONS 

Task  2:  Maintenance  Data  Implications.  Review  one  selected  USMC  end  item. 
Selected  based  on  span  of  life-cycle  acquisition  stages. 

•  Task  2.1:  Review  what  types  of  maintenance  data  that  is  currently  being 
generated.  Review  the  sources  of  this  data,  means  of  data  generation,  how  the 
data  is  stored/catalogued/reviewed/acted  upon. 

•  Task  2.2:  Review  the  selected  end  item  for  the  types  of  sensors/diagnostic  tools 
needed  to  facilitate  system  diagnostics/failure  analysis. 

•  Task  2.3:  Based  on  the  results  of  tasks  2.1  and  2.2,  recommend  a  standard 
maintenance  data  protocol  for  USMC  end  items.  The  recommended  approach 
will  include  the  following: 

o  What  data  is  required? 
o  How  the  data  will  be  generated/stored/used. 

o  Recommendations  on  what  data  system  and  communication  technologies 
are  available  to  implement  the  approach, 
o  A  recommendation  on  what  data  representation  and  data  recognition 
tools  are  available  to  transform  data  streams  into  useable  information. 

In  this  chapter  the  study  team  focused  on  maintenance  data  implications  and 
decision-making  tools.  The  following  are  addressed  in  detail.  Appropriate  cross- 
references  are  given. 

1 .  Types  of  maintenance  practices 

2.  Data  related  to  maintenance  generated 

3.  Systems  used  for  maintenance  and  supply 

4.  Decision  support  tools:  Quad  Models  and  Data  mining 

5.  Sensor  processing  and  diagnostic  tools 

3.1  Overview  on  Maintenance 

Maintenance  is  an  essential  part  for  any  system/plant  for  sustainability  of  the 
system/plant.  Monitoring  plays  a  significant  role  in  maintenance.  Depending 
upon  the  type  of  maintenance  requirements  (scheduled,  anticipatory  or  critical) 
monitoring  and  maintenance  efforts  are  closely  inter-related.  Figure  3.1  shows 
the  various  types  of  maintenance  practices.  Specific  definitions  of  the 
maintenance  types  are  detailed  in  Appendix  8.6:  IR  1  (pages  15-16). 
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3.1.1  Various  Maintenance  Types  Related  to  Monitoring 


T  iitve  based 


Time  based 


T line  based  T ime  based 


Emergency 


Machine  based 
(monitor) 


Machine  based  Machine  based 

(monitor)  (monitor) 


Figure  3.1  Types  of  Maintenance  Related  to  Monitoring 


For  our  study  we  deal  with  three  classes  of  maintenance  practices: 

•  Scheduled:  In  a  system,  this  type  of  maintenance  is  considered  to  be 
essential  and  is  scheduled  to  be  performed  during  systems  operation. 

•  Anticipatory:  By  taking  a  deteriorating  current  situation  into 
consideration,  this  type  of  maintenance  is  performed  to  prevent  any  further 
deterioration.  It  requires  a  certain  amount  of  monitoring  to  provide 
sufficient  evidence  to  initiate  appropriate  action  at  the  best  time;  however, 
it  could  be  time  based.  Theoretical  details  related  to  the  Anticipatory 
Maintenance  can  be  found  in  the  Appendix  8.6:  IR  1  (pages  17-21). 

•  Critical:  This  type  of  maintenance  comes  into  action  after  the 

system/component(s)  have  failed.  It  is  an  unplanned  event 

(maintenance),  which  results  in  high  cost  and  also  is  not  appealing  to  the 
maintenance  personal  due  to  the  unscheduled  work. 
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3.2  Current  Maintenance  Practice  within  USMC 

The  current  maintenance  procedures  use  paper-based  forms  such  as  equipment 
repair  orders  (ERO),  equipment  repair  order  shopping/transaction  lists  (EROSL) 
etc.  These  are  used  for  requisition  purposes  and  are  forwarded  to  the  specific 
maintenance  units  by  manual  means.  The  data  contained  in  these  forms  are 
later  entered  into  the  relevant  maintenance  systems  such  as  MIMMS,  Field 
Maintenance  Subsystems  (FMS)  etc.,  for  keeping  records  and  maintaining 
visibility.  These  systems  are  stove  piped  and  are  detailed  in  Appendix  8.1. 
Table  3.1  shows  the  current  maintenance  data  generated.  The  various  forms  and 
records  that  are  currently  used  for  maintenance  in  the  Marine  Corps  are 
described  in  Appendix  8.1. 

3.2.1  Types  of  Maintenance  Data  Currently  Generated 


Table  3.1:  Data  Attributes  for  ERO  and  EROSL 


Data  Attributes  I  Description 

ERO 

ERO  Number 

Equipment  Repair  Order  Number 

Acceptance  Information  (Signature) 

Signature  of  the  person  accepting  the 
equipment 

Acceptance  Date  (DRIS) 

Date  received  in  shop 

Organization  doing  repairs 

Name  of  maintenance  shop  performing  the 
repairs 

Echelon 

Echelons  of  Maintenance 

Serial  Number 

Serial  Number  of  the  Equipment 

Authorization  Information  (Signature) 

Signature  of  the  person  authorizing  the  work  to 
be  performed 

Authorization  Date 

Priority 

Priority  assigned  to  the  ERO 

ID  Number 

System  ID 

Nomenclature 

Name  and/or  model  number  of  equipment 

Job  Order  Number  (JON) 

Job  order  number  to  be  charged  for  the  repair 
parts 

Shop  Section 

Shop  section  code 

Task  Number  (Item  No.) 

Serial  number  for  task  performance  entered  in 
numerical  sequence 

Description  of  Work 

Brief  description  of  each  task 

Labor  Hours 

Total  labor  hours  to  the  nearest  1/1 0tn  of  an 
hour 

Mechanic  Information 

Signature  of  the  mechanic  performing  the 
repair 

Job  Status 
-  Code 

Code  indicating  the  job  status 

Status  Date 

Date  on  which  the  status  is  entered 

EROSL 

ERO  Number 

Equipment  Repair  Order  Number 

Unit  ID 

Unit  name  and  number  submitting  the  EROSL 

Date  Received 

Date  received  in  shop 

Date  ( 1  NIT) 

Date  the  mechanic  fills  in  the  EROSL 

Material  usage  code 

Indicates  the  type  of  part  requested 
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(accessories,  SECREPS) 

Shop  Section 

Shop  Section  Code 

Supply  IP 

NSN 

Appropriate  NSN  of  part  to  be  ordered 

3.3  Sensor  Processing 

In  recent  years,  three  major  advances  in  information  technology  have  enabled 
the  development  of  smart  systems.  These  developments  include  smart  nano- 
and  micro-scale  sensors,  wide-bandwidth  wireless  communications,  and 
improvements  in  predictive  diagnostics.  As  a  result,  systems  are  beginning  to  be 
developed  to  monitor  their  own  status  or  health,  and  predict  the  evolution 
towards  failure.  In  effect,  these  smart  systems  “feel  their  own  pain”  and  can 
announce  when  they  need  “care  and  feeding”.  New  platforms  and  weapon 
systems,  such  as  the  Expeditionary  Fighting  Vehicle  (EFV)  for  example,  are 
incorporating  sensors  and  reporting  via  wireless  communications  to  allow 
distribution  of  information  about  the  system’s  health,  operating  status,  and 
logistics  needs.  In  particular,  the  U.  S.  Marine  Corps  has  developed  an  OA  that 
will  accommodate  platform  based  sensor  observations,  generate  reports  by 
platform  operators  and  maintenance  personnel,  with  communication  of  this 
information  at  local  and  global  levels  via  wireless  communications.  The  present 
study  is  developing  this  concept  further  including;  use-cases,  physical 
architectures,  algorithms,  and  recommendations  for  improved  supply  chain 
management  and  logistics  support.  Summary  of  the  on-going  research  is 
presented  to  provide  a  glimpse  of  a  new  capability  that  will  exist  in  which 
commanders  at  multiple  levels  can  conduct  intelligent  preparation  of  the  logistics 
battle-space,  analogous  to  current  intelligent  preparation  of  the  battlefield. 

The  use  of  a  broad  spectrum  of  sensors  and  multisensor  data  fusion  provides  the 
opportunity  to  significantly  improve  the  knowledge  of  the  state  of  USMC 
resources  (platforms,  weapon  systems,  etc.).  The  expected  benefits  include 
improved  system  accuracy,  decreased  uncertainty,  and  increased  robustness  to 
changes  in  the  targets  and  environmental  conditions.  A  key  challenge  becomes 
how  to  fuse  these  data  to  achieve  inferences  that  cannot  be  achieved  using  a 
single  sensor  or  source.  This  section  of  the  report  describes  the  concept  of 
multisensor  data  fusion,  a  summary  of  the  state  of  technology  and  application  of 
data  fusion  to  condition  based  monitoring  of  systems  and  platforms. 

A  conceptual  model  for  an  intelligent  monitoring  system  is  shown  in  Figure  3.2. 
A  mechanical  system  or  military  platform  such  as  a  rotorcraft  (shown  at  the  top 
left-hand  side  of  the  figure  is  to  be  monitored  for  status  and  mechanical  health. 
Failure  mechanisms  for  such  a  system  may  include  corrosion,  wear,  lubricant 
contamination  or  degradation,  thermo-mechanical  fatigue,  etc.  These  failures  are 
typically  flight  or  safety  of  flight  critical.  The  intelligent  monitoring  system  shown 
in  Figure  3.2  has  multiple  components  and  functions  including;  (1)  active  and 
passive  sensors,  (2)  signal  processing  and  feature  extraction,  (3)  pattern 
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classification,  (4)  multi-sensor  data  fusion,  (5)  automated  reasoning,  (6)  models, 
(7)  historical  data  input,  (8)  mission  constraints,  and  (9)  human-in-the-loop 
decision  making. 


Sensing 


/*■ 

/  Class 


Classification 


History 


Figure  3.2  Concept  of  an  Intelligent  Monitoring  System 


A  special  aspect  of  this  research  involves  developing  data  fusion  algorithms  to 
improve  logistics  support.  A  goal  of  this  study  is  to  establish  templates  that  can 
apply  to  any  piece  of  ground  equipment  with  a  standard  means  to  deploy 
diagnostics/prognostics,  track,  evaluate,  anticipate  failure,  activate  the 
supply/maintenance  system  to  request,  order  and  repair  the  item  based  upon 
varying  time  constraint  scenarios.  Indeed,  data  fusion  assists  in  this  objective 
greatly  due  to  its  ability  to  abstract  the  data  into  information  to  be  utilized  at 
higher  levels  of  the  system  hierarchy.  Data  fusion  is  applicable  at  all  levels  of  the 
system  hierarchy.  At  the  lower  levels  its  goal  is  to  bring  together  diverse  data 
sources  and  extract  key  information  that  is  indicative  of  the  equipment  condition. 
At  the  intermediate  levels,  its  goal  is  to  integrate  diverse  information  sources  to 
evaluate  the  system  behavior  and  assess  its  ability  to  handle  its  mission.  In 
addition,  at  this  level  actions  for  maintenance  and  mission  re-planning  could  be 
generated.  At  the  higher  levels,  the  goal  is  to  provide  contextual,  actionable 
information  to  various  users  in  the  networked  enterprise.  Templates  have  been 
developed  to  help  practitioners  develop  diagnostic  processing  solutions  for 
USMC  equipment.  Some  initial  templates  are  presented  in  Chapter  5. 

This  section  of  the  report  describes  the  concept  of  multisensor  data  fusion, 
assessment  of  the  state  of  technology  and  application  of  data  fusion  to  condition 
based  monitoring  of  systems  and  platforms.  Examples  of  these  applications  to 
rotorcraft  and  land  vehicles  are  provided  in  Appendix  8.7:  IR  2/3.  The  examples 
of  systems  provided  in  this  review  present  some  demonstrations  at  various 
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levels.  A  brief  summary  is  also  provided  of  application  of  information  fusion  for: 
(1)  Monitoring  the  condition  of  individual  LAVs  and  (2)  Monitoring  the  location 
and  health  of  several  LAVs  in  a  networked,  enterprise  setting.  The  methods  and 
techniques  described  in  the  fault  diagnosis  examples  are  not  limited  to  air 
vehicles.  They  can  be  used  on  a  variety  of  mechanical  equipment  in  military  and 
industrial  settings.  In  fact,  systems  employing  such  techniques  are  presently 
being  tested  by  the  US  Navy  and  US  Army  for  their  rotorcraft  applications.  Also, 
several  industrial  systems  for  fault  diagnosis  are  becoming  available.  The 
importance  of  presenting  the  appropriate  information  to  the  user  is  now  being 
recognized  in  the  implementation  of  diagnostic/prognostic  systems.  In  Table  3.2, 
column  1  refers  to  the  various  sections  related  to  Sensor  Fusion  and  Fault 
Diagnosis  and  column  2  specifies  where  these  details  can  be  found  in  the 
previous  IR  and  its  corresponding  page  numbers. 


Table  3.2:  Sensor  Fusion  and  Fault  Diagnosis  References 


Sensor  Fusion  and  Fault  Diagnosis 

Section 

Reference 

Concept  and  Model  for  Data  Fusion 

Appendix  8.7:  Interim  Report  2/3  Paqes 

33-34 

JDL  model  for  Data  Fusion 

Appendix  8  7:lnterim  Report  2/3  Paqes 

35-36 

Pit  Falls  in  Data  Fusion 

Appendix  8  7:lnterim  Report  2/3  Paqes 

36-37 

Application  of  Data  Fusion  to  Diagnosis 

Appendix  8  7:  Interim  Report  2/3  Paqes 

38-39 

Fault  Diagnostics  Examples:  Feature  Level  Fusion 

Appendix  8  7:  Interim  Report  2/3  Paqes 

39-43 

Fault  Diagnostics  Examples:  Decision  Level  Fusion 

Appendix  8.7:lnterim  Report  2/3  Paqes 

43-45 

LAV  Top  Degrader  Study 

Appendix  8.7 interim  Report  2/3  Paqes 

45-50 

Additional  details  related  to  Sensor  Fusion  and  Fault  Diaqnosis  were  also  documented  in  the  Appendix  8.6: 
Interim  Report  1  (Appendix  4  Paqes  98-116)  :  Appendix  8.7:  Interim  Report  2/3  (Appendix  7.4  Paqes 

83-94). 

3.4  Data  Mining  and  Decision  Support 

3.4.1  Quadrant  Model  Review 

The  quadrant  model  is  a  classification  tool  used  to  categorize  the  elements  along 
two  distinctly  different  attributes.  Relevant  to  this  study,  the  attributes  considered 
are  the  mission  value  and  risk/uniqueness.  The  main  computation  performed  in 
this  model  is  the  quantification  of  risk  and  mission  value  associated  with  the 
different  components.  In  the  generic  quadrant  model,  the  X-axis  represents  the 
mission  value  of  a  particular  component  and  the  Y-axis  represents  the 
risk/uniqueness  associated  with  the  components.  The  value  from  left  to  right  on 
the  X-axis  and  bottom  to  up  on  the  Y-axis  increases  from  low  to  high. 

The  quadrant  model  has  two  ‘dividers’  that  partition  the  X  -Y  plane  into  four 
distinct  quadrants.  They  are  categorized  as  “Routine,  Leveraged,  Bottleneck  and 
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Critical”.  Each  of  the  quadrants  represents  components  with  distinct  levels  of  risk 
and  mission  value.  The  dividers  can  be  adjusted  to  change  the  fraction  of 
components  falling  into  the  four  categories.  Figure  3.3  shows  the  quadrant  model 
with  a  sample  of  the  attributes  that  ascertain  which  components  belong  to  the 
respective  quadrants. 
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Figure  3.3  Quadrant  Model  Showing  the  Attributes  &  a  Sample  of  the 
Various  Criteria  that  Determine  which  Component  Belongs  to  the 
Respective  Quadrants. 


With  the  above  concept,  specific  business  rules  can  be  applied  for  each  category 
to  assist  in  decision  making  at  various  levels.  In  addition,  this  will  help  in 
identifying  critical  components  in  the  LAV  for  which  CBM  can  be  enforced  for 
diagnosis  and  prognosis. 

The  quadrant  model  assists  in  decision-making.  Apart  from  the  quadrant  model, 
various  techniques  are  available  for  analysis.  One  such  technique  considered  is 
“Data  mining”.  Combining  data  mining  techniques  with  the  quadrant  model  can 
improve  the  granularity  of  classification  of  SECREPS.  The  study  team  had 
discussions  with  Capt.  Jake  Enholm  who  had  been  working  on  the  quad  model. 
The  work  is  deemed  to  be  complementary.  The  study  team  investigated  a 
methodology  to  do  the  transformation  of  attributes  for  plotting  using  tensor 
calculus  in  support  of  Capt.  Enholm’s  efforts.  Those  initial  results  are  promising 
and  bear  further  future  study. 


3.4.2  Decision  Support  Systems  with  Data  Mining 

In  this  study,  Data  mining  techniques  are  needed  to  support  maintenance  related 
decisions  that  are  made  at  different  levels  (Strategic,  Operational  and  Tactical) 
within  the  USMC.  In  the  quadrant  model,  all  the  parts  that  are  classified  as  critical 
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are  treated  according  to  the  same  business  rules.  There  is  not  much  scope  for 
prioritizing  the  requirements  of  components  within  each  category  of  the  quadrant 
model.  To  achieve  greater  granularity  the  use  of  other  data  mining  techniques  is 
suggested. 

The  primary  decision  considered  here  is  that  of  prioritizing  the  procurement  of 
components  within  a  fixed  budget.  The  input  data  considered  are  similar  to  those 
used  for  the  quadrant  model  analysis  (provided  by  the  sponsors).  Data  elements 
used  were  from  the  FEDLOG,  Logistics  Data  Repository  (LDR),  Supply  chain 
management  center,  in  combination  with  some  of  the  simulation  results. 

Though  the  decision  considered  here  is  at  the  strategic  level,  similar  techniques 
can  be  considered  for  the  operational  and  tactical  levels.  At  the  strategic  level, 
the  main  objective  is  to  limit  the  costs  incurred  as  part  of  maintenance 
procurement,  while  at  the  tactical  level  the  emphasis  would  be  on  the  availability 
of  the  required  components.  The  decisions  made  at  the  strategic  level  would  be 
based  on  historical  (long  term)  data  while  the  tactical  level  decisions  would  be 
made  in  near  real  time.  It  is  important  that  the  decision  support  system 
developed  be  aligned  along  the  three  different  levels  to  improve  operational 
efficiency.  Figure  3.4  shows  the  overview  of  the  processing  element  for  data 
mining. 


MAIN  PROCESSOR  FOR  THE  DAT  ALIENING 


Figure  3.4  Processing  Elements  for  Data  Mining 
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3.4.3  Data  Mining  Implementation  Techniques 

In  Table  3.3,  Column  1  specifies  the  data  mining  implementation  techniques  for 
IDGE  and  Column  2  specifies  its  relevant  Appendix  and  IR  and  page  numbers. 


Table  3.3:  Data  Mining  Implementation  Techniques  References 


Data  Mining  Implementation  Techniques 

Section 

Reference 

Implementation  of  Data  Mining  Techniques 

Appendix  8. 7: Interim  Report  2/3  Paaes 

26-27 

Implementation  of  Classification  Algorithm  using 

MATLAB 

Appendix  8.7:lnterim  Report  2/3  Paaes 

27-28 

Validation  and  Evaluation  of  Data  Mining  Techniques 

Appendix  8  7:lnterim  Report  2/3  Paae 

28 

Misclassification  Error  rate  of  Classification  Algorithms 
and  Principal  Component  Analysis 

Appendix  8.7:lnterim  Report  2/3  Paaes 

28-29 

Sensitivity  and  Specificity  Analysis  of  Classification 
Algorithms  with  Principal  Component  Analysis 

Appendix  8  7:lnterim  Report  2/3  Paqes 

30-31 

Fundamental  concepts  of  Data  Minina  are  presented  in  the  Appendix  8.6:  Interim  Report  1: 

Chapter  6  (paqes  44-52). 

Theoretical  details  related  to  the  various  Data  mimnq  techniques  are  documented  in  the  Appendix 

8  7:  Interim  Report  2/3  (Appendix  7.3,  Paqes  74-82). 
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4  LOGISTICS  SYSTEM  INFORMATION 

Task  3:  Logistics  Systems  Information.  Review  the  suitability  of  current  and  future 
logistics  systems  to  use  the  maintenance  information  generated  to  make  logistic  support 
decisions  for  the  selected  USMC  end  item  and  future  systems. 

•  Task  3.1:  Determine  the  quantity/quality/timeliness  of  information  to  be  used  at: 

o  The  unit/end  item  level 
o  The  Marine  Expeditionary  Brigade  (MEB)  level 
o  The  HQMC/SYSCOM/MCLC  level 

•  Task  3.2:  Review  candidate  decision  tool  technologies  and  recommend  which 
are  most  suitable  for  implementation. 

The  OA  forms  the  foundation  to  the  USMC  future  logistics  systems.  In  order  to 
develop  the  architecture  for  the  USMC  maintenance  logistics  system,  the  team 
executed  the  following  logical  steps. 

-  Using  the  OA,  specific  cases  relevant  to  maintenance  were  identified 

-  Details  regarding  the  information  exchange  between  the  nodes 
(organizations)  were  captured 

-  The  specific  data  attributes  that  is  to  be  sent  from  node  to  node  were 
identified 

-  The  nodes  within  the  maintenance  cases  were  mapped  to  specific 
organizations  within  USMC 

Using  this  mapping,  possible  scenarios  were  generated 

-  Identified  nodes  (organizations)  within  these  scenarios  where  decision 
making  is  required 

-  The  data  that  needs  to  be  captured  to  support  each  of  these  decisions  at 
the  nodes  were  identified 

Recommendations  were  made  for  the  type  of  analysis  that  needs  to  be 
done  and  to  support  these  decisions 

-  The  system  and  technologies  that  would  enable  the  exchange  of  the 
required  information  were  identified 


4. 1  Use  Case  Analysis 

4.1.1  Why  Use  Cases 

Following  the  top-down  perspective,  that  is,  a  user-driven  analysis,  we  propose 
the  use  of  use  cases  to  document  current  and  envisioned  practices  that  users  of 
IDGE  will  use.  Use  cases  allows  the  documentation  of  scenarios  using  the 
terminology  of  potential  users  in  a  manner  that  clarifies  how  the  proposed  system 
will,  in  fact,  be  used  by  the  users.  These  are  documented  to  understand  the 
decisions  the  actors  make,  the  data  the  actors  use,  how  they  communicate  with 
one  another  as  well  as  the  system,  as  well  as  to  understand  the  limitations  of 
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constructing  the  system.  Our  efforts  at  creating  these  use  cases  are,  therefore, 
informed  by  the  following: 

.  We  assume  that  the  envisioned  use  cases  will  follow  an  anchor  and  adjust 
strategy,  that  is,  the  current  practices  will  be  respected  to  the  extent  possible. 

.  We  assume  that  the  envisioned  use  cases  will  provide  a  path  to  use  current 
legacy  systems  in  the  near  term  with  an  extension  to  a  full-blown  IDGE 
system  in  the  future 

.  We  assume  that  the  informal,  social  practices  that  make  the  current  practices 
work  will  be  retained,  to  the  extent  possible,  in  the  proposed  practices,  to 
ensure  that  the  benefits  of  these  are  not  lost 

4.1.2  Understanding  Use  Cases 

A  Use  Case  is  a  description  of  the  interaction  of  a  potential  user  with  an 
envisioned  system  (Jacobson  et  al.  1995).  The  description  contains  sufficient 
information  that  allows  progress  during  the  analysis  without  final  commitment.  A 
use  case  is  written  using  terminology  that  is  familiar  to  the  potential  users.  A 
single  Use  Case,  thus,  represents  a  unit  of  analysis  that  (a)  potential  users  can 
relate  to  and  confirm,  (2)  designers  can  build  and  deploy,  (3)  implementers  can 
test,  and  (4)  project  managers  can  use  to  estimate  effort.  Further  background 
information  about  use  cases,  how  they  are  documented,  their  benefits,  and  how 
they  can  be  utilized  for  different  purposes  can  be  found  in  (Appendix  8.7:  IR2/3, 
Chapter  3). 

Figure  4.1  below  shows  the  basic  use  case  notation.  An  actor  (stick  figure) 
represents  the  role  played  by  a  potential  user.  A  use  case  (oval)  is  the 
description  of  interactions  that  an  individual  actor  will  carry  out  with  a  system 
(OMG  2004).  In  addition,  functional  groupings  of  use  cases  are  sometimes 
referred  to  as  packages  (rectangle). 
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Figure  4.1  Notations  for  Use  Cases 
4.1.3  Creating  Use  Cases  to  Envision  IDGE 

The  previous  Interim  Reports  (Appendix  8.7:  IR2/3,  Chapter  3)  outlined  the 
process  we  had  initiated  for  constructing  the  use  cases.  Here,  we  report  updates 
to  this  process,  including  how  it  was  adapted  for  the  current  project. 

The  key  participants  in  the  early  phases  of  the  process  included  Major  Blake  and 
Colonel  Grimes,  who  provided  valuable  inputs  to  the  early  versions  of  the  use 
cases.  These  were  followed  by  multiple  iterations  of  the  use  cases  within  the 
team,  and  during  the  months  of  March  and  April,  were  validated  by  visits  to  the 
Schoolhouse  in  Aberdeen,  MD,  and  the  Logistics  Depot  at  Albany,  GA. 

An  infrastructure  -  primarily  containing  the  hardware  -  was  created  following  the 
preliminary  discussions  with  Col.  Grimes  and  Maj.  Blake.  This  is  also  available  in 
the  previous  interim  report  (Figure  3.3,  (Appendix  8.7:  IR2/3,  Chapter  3)). 

Based  on  an  investigation  of  how  in-theatre  and  in-depot  maintenance  is  done,  a 
total  of  25  use  cases  were  initially  created,  which  were  revised  following  further 
discussions  and  changes  following  the  visit  to  Albany,  GA.  At  final  count  a  total  of 
31  use  cases  have  been  documented  and  are  part  of  this  final  report.  Figure  4.3 
shows  the  summary  of  the  use  cases. 
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We  realize  that  the  figure  is  difficult  to  read.  The  complete  set  of  use  cases  is 
shown  in  Appendix  8.4.1  and  is  available  for  browsing  in  a  hyperlinked  format 
using  the  web  browser  by  opening  the  file  idqe-usecase.zip  (enclosed  on  the  CD 
supplied  with  this  final  report).  The  software  needed  to  view  these  use  cases  is 
any  web  browser  such  as  Internet  Explorer.  Figure  4.2A  shows  a  screen 
snapshot  of  the  browsable  set  of  use  cases. 
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Figure  4.2A  Use  Cases  for  Browsing  (enclosed  on  the  CD) 


The  Figure  4.2A  shows  the  browsable  use  cases.  The  left  pane  shows  the  list  of 
use  cases  constructed.  The  right  pane  shows  the  use  case  diagram.  Selecting 
any  of  the  use  cases  will  display  the  use  case  documentation  for  that  use  case. 
The  figure  above  shows  how  selecting  “Use  Case  2:  Query  a  sensor”  will  display 
the  documentation  in  a  new  window. 

The  detail  captured  in  the  use  case  has  improved  considerably  through  the 
revisions  and  the  information  contained  and  can  be  considered  valid  following  the 
visits  to  Aberdeen,  MD,  and  Albany,  GA.  An  example  use  case  is  shown  in 
Figure  4.3. 
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Use  Case:  Periodically  upload  sensor  data  from  black  box  in  each  LAV 

Preconditions: 

•  Existing  wireless  technology  for  communication  between  the  field  and  the  battalion  level. 

•  Black  box  in  place  at  the  LAV  to  collect  the  data  from  multiple  sensors  in  the  LAV 

•  Transmitter  system  in  place  at  the  LAV  to  transmit  the  sensor  signals  from  the  black  box. 

•  Receiver  system  is  in  place  at  the  battalion  to  receive  the  signals  and  pre-process. 

Actors: 

•  Maintenance  person  at  battalion  level 

•  Maintenance  analyst  at  battalion  level 

Goal: 

To  successfully  upload  sensor  data  from  each  vehicle  at  predetermined  intervals 

Flow  of  events: 

1  Transmitter  at  the  LAV  uploads,  at  a  predetermined  time,  sensor  data  collected  over  the  last 
period,  currently  specified  at  24  hours  (preferred  course  of  action  when  LAV  is  far  from  base). 

2.  Receiver  at  the  battalion  level  authenticates  source  of  data  stream  from  field  to  ensure  that  it 
originates  from  a  validated  vehicle. 

3.  The  processor  at  the  battalion  level  verified/decodes  the  signal. 

4.  If  successful,  the  battalion  level  analyst  releases  the  data  stream  for  storages  j  Retaining 

and  update  of  the  database  (manual  check  necessary  to  ensure  integrity  of  i  human-in- 
the  database).  j  the-ioop 

Alternative  flow  1 : 

1 .  If  the  LAV  operator  notices  a  problem  with  the  LAV  but  cannot  determine  the  :  Retaining 
case,  he  may  initiate  an  upload  before  the  scheduled  time.  The  remaining  |  current 
steps  for  the  upload  remain  the  same.  I  practice 

Alternative  flow  2: 

1 .  If  an  upload  could  not  be  attempted  or  was  not  successful  for  any  reason,  the  black  box  continues 
to  store  sensor  data  for  the  most  current  24  hours. 

2  At  the  next  predetermined  time,  the  upload  is  again  attempted.  The  remaining  steps  stay  the 
same 


Preamble 


Flow(s) 


Alternative  flow  3: 


Retaining  the 
social  and 
informal 


1 .  Every  day,  an  LAV  mechanic  visits  the  front  where  the  LAVs  are  deployed 
with  a  notebook  (preferred  course  of  action  when  LAV  is  not  far  from  base 
-  in  order  to  present  a  friendly  face  to  the  crew) 

2.  The  mechanic  downloads  the  contents  of  the  black  box  into  the  notebook  with  a  hardwired 
connection. 

3.  The  mechanic  returns  to  base  and  uploads  from  the  notebook  to  the  history  database. 

Frequency  and  levels: 

•  Once  a  day  for  each  LAV 

•  Vehicle  level,  Battalion  level 

Data  implications: 

Sensor  stream  data  moved  from  the  black  box  to  the  history  database 

Algorithms  and  Decision  Support  tools: 


Implications 


Figure  4.3  Sample  Use  Case 
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The  example  shows  (see  inset  boxes)  how  the  use  cases  attempt  to  retain  use  of 
current  procedure,  and  maintain  the  social  and  informal  practices  that  would 
provide  greater  acceptance  of  the  envisioned  IDGE  system. 

The  use  case  also  shows  that  a  battalion  level  analyst  may  be  charged  with  the 
task  of  ensuring  that  the  data  stream  from  the  sensors  is  not  spurious.  This 
aspect  of  the  use  case  demonstrates  the  effort  during  the  analysis  to  ensure  that 
a  human  actor  is  added  to  the  scenarios  to  operationalize  the  notion  of  ‘challenge 
and  respond.’  Because  open  system  architecture  will  be  the  favored  alternative 
for  eventual  implementation  of  an  IDGE  system,  this  step  is  necessary  as  a 
means  of  introducing  security.  It  is  indeed  possible  to  offload  this  task  to 
intelligent  agents  (e.g.  CLC2S  with  intelligent  agents)  as  the  implementation  and 
the  relevant  technology  is  more  stable  and  mature.  The  human  actor  as 
described  in  the  use  case  above,  therefore,  operationalize  inserting  the  human  in 
the  loop  that  is  akin  to  'challenge  and  respond,'  and  will  apply  in  both  field  and 
garrison. 

It  should  be  noted  that  the  preconditions  specified  for  the  use  cases  provide 
considerable  information  about  strategies  that  may  be  devised  for  implementing 
these  scenarios.  For  example,  the  use  case  shown  in  Figure  4.3  indicates  that  it 
presupposes  existing  wireless  technology  in  place  for  communication  between 
the  field  and  the  battalion  level.  A  modified  version  of  the  use  case  (e.g.  the  one 
specified  in  alternative  flow  3  in  the  documentation  in  the  figure  below)  may  be 
used  as  an  intermediate  step  towards  attaining  the  scenario  that  requires  the 
wireless  technology  in  place.  Issues  of  reliability  can  then  be  explored  in  the 
context  of  the  precondition  of  existing  wireless  technology  by  comparing  the 
existence  of  one  or  more  of  the  alternatives  such  as  mesh  network,  wireless 
LAN,  cellular  networks  and  satellite  networks.  More  detailed  analyses  of  these 
will  require  use  of  detailed  studies  about  wireless  technologies. 


4.1 .4  Creating  User  Interfaces  as  the  Visible  Component  of  IDGE 

Each  of  the  use  cases  created  is  accompanied  by  a  detailed  outline  of  a  user 
interface  that  would  provide  the  visible  face  to  the  use  case.  This  technique, 
sometimes  referred  to  as  wireframe  diagrams  (Malone  2000),  is  useful  to 
understand  the  capabilities  of  the  proposed  system.  It  can  also  provide  the  users 
a  snapshot  of  how  the  system  may  appear,  and  provide  future  designers  and 
implementers  of  the  system  a  starting  point  for  implementation. 

Figure  4.4  below  shows  a  snapshot  of  a  user  interface  created  for  a  different  use 
case.  This  snapshot  captures  the  interface  that  the  driver  of  an  LAV  might  use  to 
report  a  breakdown  from  the  field.  Based  on  the  discussions  with  potential  users 
and  the  maintainers,  the  interface  shows  minimal  data  but  captures  the  essential 
elements  that  the  users  indicate  as  key  for  making  future  decisions. 
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User  Interface  for:  Report  a  Breakdown  from  the  Field 


Envisioned 
Reporting 
from  a  PDA 


Figure  4.4  Sample  User  Interface 

The  complete  set  of  user  interfaces  is  interspersed  with  use  cases  shown  in 
Appendix  8.4.1.  The  user  interface(s)  designed  to  capture  the  interface 
component  of  that  use  case  follows  each  use  case. 

The  use  cases  and  user  interfaces  presented  here  for  real-time  maintenance  and 
tracking  are  likely  to  be  viable  but  it  is  difficult  to  tell  without  setting  up  some 
simulations  and  actual  prototypes  and  testing.  At  least  two  further  steps  are 
necessary  to  ensure  that  a  meaningful  development  process  is  implemented. 
The  first  step  in  this  will  involve  simulation  of  the  proposed  system  -  in  concert 
with  anticipating  changes  to  the  people  and  procedures;  and  the  second  step  will 
involve  the  actual  prototyping.  Efforts  under  way  at  Penn  State  ARL  regarding 
viability  of  monitoring  the  health  of  a  vehicle  with  sensors  can  be  leveraged  as 
the  starting  point  for  such  prototyping.  Viewed  in  this  manner,  the  interfaces  and 
on-line  systems  represent  a  possible  goal,  but  will  need  to  be  validated  and 
adjusted  based  on  any  system  simulation  and  prototyping  briefly  described 
above.  An  initiative  to  fully  implement  the  use  cases  and  user  interfaces,  then, 
would  need  to  follow  an  iterative  strategy,  starting  with  simple  scenarios,  and 
building  on  these  to  include  the  more  demanding  ones  instead  of  attempting 
implementation  of  the  entire  set  of  scenarios  in  a  single  all-encompassing  effort. 
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4.1.5  Understanding  Data  Implications 

The  format  we  have  followed  for  documenting  the  use  cases  also  provides  an 
excellent  jump-off  point  for  understanding  the  aggregate  data  implications  of  the 
proposed  use  cases.  This  information  can  be  captured  from  the  use  cases  by 
examining  the  data  implications  (see  Figure  4.3  above).  Aggregating  this 
information  across  the  use  cases,  then,  provides  sufficient  information  about  the 
aggregate  data  transferred  across  different  levels  of  the  infrastructure  (Purao  et 
al  1995). 

The  conceptualization  of  the  infrastructure  levels  used  in  this  report  is  mapped  to 
the  organizational  levels  identified  in  the  logistics  modernization  efforts  of  the 
Marine  Corps.  Our  infrastructure  levels,  therefore,  correspond  directly  to  the 
revised  number  of  levels  proposed  by  logistics  modernization  efforts  that  require 
shifting  from  the  old  five  to  the  new  three  echelons  of  maintenance. 
https://mcss.quantico.usmc.mil/studvsinqle.asp?scn=DM980402.  We  have  added 
the  vehicle  itself  as  a  separate  level  in  addition  to  these  three  because  of  our 
interest  in  identifying  aggregate  data  communications  across  these  levels. 
Further,  to  clarify  whether  the  communication  is  between  command  and/or 
maintenance,  we  have  labeled  each  level  with  a  prefix  of  C’  or  ‘M’  to  indicate  the 
possible  roles  actors  may  play  at  each  level.  For  example,  for  the  O-level,  we 
have  labeled  the  possible  roles  as  Cl  and  Ml,  for  the  l-level  as  C2  and  M2,  and 
for  the  D-level  as  C3  and  M3.  These  merely  act  as  clarifications  of  roles  at  each 
level  and  do  not  add  any  complexity  to  either  the  echelons  identified  by  the 
Marine  Corps  nor  to  our  analysis.  For  each  use  case,  then,  the  data 
communication  is  specified  as  between  these  levels  e.g.  Cl  to  Ml  or  Cl  to  M2 
etc.  The  levels  are  summarized  below: 

.  The  Vehicle  Level  (in  our  exemplar,  the  LAV)  -  Vehicle  level 
.  The  O-Level  (connecting  to  the  Battalion  level  and  the  vehicle  level)  -  Cl ,  Ml 
.  The  1-Level  (connecting  to  the  MEB  and  the  MEF)  -  C2,  M2 
•  The  D-Level  (connecting  to  the  MEF  and  the  Sea-Base)  -  C3,  M3 

As  an  example,  consider  the  use  case  specified  in  Figure  4.3  above,  or  the  user 
interface  shown  in  Figure  4.4  above.  Each  provides  the  data  generated  and 
transferred  across  levels  of  the  infrastructure.  Figure  4.5  below  shows  how  this 
information  can  be  aggregated.  The  first  row  refers  to  the  use  case  shown  in 
Figure  4.3,  and  the  second  row  refers  to  the  user  interface  shown  in  Figure  4.3. 
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From 

To 

Frequency 

Description 

Type  of  Data 

Volume  of  Data 

Min 

Max 

Min 

Max 

1 

II 

1 

1 

Sensor  Data  transferred 
from  Black  Box  to  History 
database 

Sensor  Data 
Stream 

5  MB 

5  MB 

1 

II 

1 

3 

Breakdown  report 
transferred  from  LAV  to 
Battalion  Analyst 

ID,  mileage, 
problem  code, 
problem  description 

2KB 

6KB 

Figure  4.5  Implications  of  Use  Cases 

(See  a  condensed  and  more  efficient  version  in  Appendix  8.4.2) 

A  more  condensed  spreadsheet  showing  the  computation  for  all  the  use  cases 
constructed  in  shown  in  Appendix  8.4.2.  That  appendix  also  shows  the  aggregate 
for  the  data  transmission  implications  based  on  the  data  generated  and  used  by 
actors  carrying  out  these  scenarios. 
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Template  1 


Template  Name: 

Creating  Use  Cases 

Purpose: 

Capture  envisioned  practices  to  ensure  that  they  are  not  in  conflict  with 
existing  practices  and  can  provide  adequate  documentation  for  future 
implementation 

Process  for  Creating 
Use  Cases: 

1.  Create  an  infrastructure  to  identify  organizational  levels  involved  (for 
an  example,  see  Figure  3.3,  Chapter  3,  IDGE  Interim  Report,  January 
2004. 

2.  Interview  potential  users  from  the  maintenance  side  as  well  as 
supply  side  (for  the  exemplar,  LAV,  visits  were  made  to  Aberdeen 
Proving  Grounds,  MD,  and  Logistics  Depot,  Albany,  GA.) 

3.  Represent  processes  they  follow  using  the  users’  terminology  (for 
example,  use  terms  and  acronyms  such  as  ERO) 

4.  Use  an  anchor-and-adjust  strategy  to  retain  current  practices  (for 
example,  see  Figure  4.2  in  this  report  that  shows  how  the  proposed 
use  case  allowed  retaining  current  practices) 

5.  Ensure  that  the  discussions  reveal  informal  practices,  which  inform 
the  use  case  documentation  (for  example,  see  Figure  4.2  in  this  report 
that  shows  how  the  proposed  use  case  allowed  retaining  current 
practices) 

Expected  Time 
Commitments: 

1.  Expect  to  spend  approximately  90  minutes  per  use  case  for  the  first 
iteration 

2.  On  subsequent  iterations,  expect  to  spend  anywhere  between  15 
minutes  to  2  hours  per  use  case. 

3.  Be  prepared  to  obtain  commitments  from  subject  matter  experts 
(SMEs),  who  will  participate  with  you  in  this  process. 

Caveats: 

1 .  Ensure  that  the  users  are  involved  from  the  very  beginning. 

2.  Ensure  that  the  use  cases  do  not  delve  into  too  much  technical  detail 
(for  example,  see  the  manner  in  which  preconditions  have  been 
specified  in  Figure  4.2  in  this  report) 

3.  Be  prepared  to  revise  the  use  cases  several  times  (for  example,  the 
use  cases  have  undergone  several  iterations  during  this  project.  One 
version  of  the  use  cases  can  be  seen  in  the  Appendices  to  the  IDGE 
Interim  Report,  January  2004.  The  most  recent  version  is  presented  in 
Appendix  8.4  of  this  Final  Report). 
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Template  2 


Template  Name: 

Documenting  Use  Cases 

Purpose: 

Follow  a  standard  template  for  documenting  the  use  cases 

Use  Case 
Documentation: 

Use  Case:  Specify  name  that  includes  an  active  verb-subject 

phrase 

Preconditions: 

•  Specify  preconditions  including  any  technology  base  that  is  assumed 

Actors: 

•  Specify  actors  engaged  with  performing  the  use  case 

Goal: 

Specify  the  goal  in  terms  of  end-result  to  be  achieved 

Flow  of  events: 

1 .  Specify  flow  as  a  sequence  of  events 

2.  Specify  the  performer  of  each  event  i.e.  write  active  sentences. 

Alternative  flow  1 . 

1 .  If  there  are  other  possibilities  in  the  interaction,  specify  these  as  alternative 
scenarios. 

Frequency  and  levels: 

•  Specify  in  as  much  detail  as  possible,  the  frequency  of  each  scenario 

Data  implications: 

Specify,  with  as  much  detail  as  possible,  data  used  and  generated  by  the  use 
case 

Algorithms  and  Decision  Support  tools: 

Identify  algorithms  and  decision  support  tools  and  techniques,  if  any, 
necessary  for  each  use  case 

Software  Packages: 

The  de  facto  standard  for  documenting  use  cases  is  Rational  Rose, 
which  is  now  owned  by  IBM  after  they  acquired  Rational  Software.  This 
is  available  for  30-dav  evaluation  at  htto;//www  rational.com. 

A  number  of  other  possibilities  are  available,  including  shareware  tools, 
which  are  listed  at 

http: //www  obiectsbvdesian.com/tools/umltools  bvComDanv.html.  Of 

these,  one  respectable  tool  is  Argo  UML  by  Tigris. 
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Template  3 


Template  Name: 

Creating  User  Interfaces  (Wire-frame  Diagrams) 

Purpose: 

Generate  a  user  interface  for  the  scenarios  identified  in  the  form  of  use 
cases. 

Process  for  creating 
wire-frame  diagrams: 

1.  Examine  the  use  case  statements  to  identify  points  of  interaction 
between  the  users/environment  and  the  proposed  information  system. 

2.  Create  a  graphical  representation  of  the  potential  user  interface  that 
may  support  the  use  case  statement(s). 

3.  Validate  the  graphical  user  interface  with  the  potential  users,  when 
possible. 

4.  Identify  as  much  of  the  data  elements  as  possible  and  specify  these 
using  users'  terminology  as  part  of  the  user  interface. 

5.  Use  standard  elements  of  the  user  interface  such  as  ‘drop-down 
box,’  'input  box,’  ‘selection  buttons,’  'radio  buttons’  etc. 

Software  Packages: 

There  does  not  appear  to  be  a  de  jure  or  de  facto  standard  for 
documenting  the  wire-frame  diagrams, 

The  diagrams  may  be  created  using  software  such  as  Visio 
(www.visio  com),  since  acauired  bv  Microsoft  or  software  such  as 
AutoCAD  (www.autocad.com).  The  diaqrams  shown  in  this  report 
were  constructed  using  AutoCAD. 

Template  4 


Template  Name: 

Using  Use  Cases  and  Wire-frame  Diagrams 

Purpose: 

Use  the  use  cases  and  wire-frame  diagrams  for  deriving  aggregate 
data  requirements  across  different  levels  of  the  underlying 
infrastructure. 

Process  for  deriving 
aggregate  data 
requirements: 

1 .  Identify,  using  the  wire-frame  diagrams,  data  elements  that  are 
transmitted  (entered  by  the  users  or  extracted  from  the  database) 
across  different  levels  of  the  infrastructure, 

2.  Assign  sizes  to  the  data  elements. 

3.  Revert  to  the  interviewees  to  obtain  frequencies  of  use  cases  if  not 
already  identified  during  the  process  of  creating  use  cases. 

4.  For  use  cases  that  are  connected  use  probabilities  to  estimate 
frequencies  e.g.  one  every  ten  vehicles  cannot  be  diagnosed  and 
needs  to  be  escalated  for  diagnosis  to  the  higher  echelon 

5.  Generate  the  data  volume  transmitted  as  the  product  of  size  of  data 
elements,  frequency  of  use  case,  and  size  of  fleet. 

Software  Packages: 

Spreadsheet  management  software  such  as  Microsoft  Excel  is 
sufficient  for  this  purpose.  The  spreadsheet  for  calculating  the  data 
transmission  can  be  specified  as  the  following  columns. 

Use  Case,  Size  of  Data,  Frequency,  Transferred  from,  Transferred  to 

If  additional  information  is  desired  such  as  minimum  and  maximum 
frequencies  and  description  of  data,  these  columns  may  be  added  in 
the  manner  shown  in  figure  4.4. 
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4.2  Marine  Corps  Future  Logistics  Systems 

The  future  Marine  Corps  Logistics  systems  will  use  the  Operational  Architecture 
developed  by  the  USMC  as  their  conceptual  foundation.  The  five  significant 
elements  identified  by  the  OA  are: 

•  Request  Management  (RM) 

•  Order  Management  (OM) 

•  Capacity  Management  (CM) 

•  Production  Management  (PM) 

•  Execution  (E) 

These  elements  are  common  across  all  the  nine  USMC  functional  areas.  For 
this  study,  we  considered  a  specific  functional  area  -  maintenance.  Three 
different  maintenance  processes  are  identified  within  the  OA  and  are  as  follows: 

•  Maintenance  at  Supported  Unit 

•  Maintenance  at  Intermediate  Maintenance  Activity  (IMA) 

•  Return  of  MRO  to  Stock 

The  node-to-node  information  flows  for  the  above  three  maintenance  processes 
were  generated.  In  addition  to  this,  the  specific  data  attributes  that  are 
exchanged  between  the  nodes  at  each  step  were  captured.  Figure  4.5  shows 
the  node-to-node  information  flow  and  Table  4.1  captures  the  data  attributes 
exchanged  between  the  nodes  for  Maintenance  at  Supported  Unit. 

Similar  tables  and  information  flows  for  Maintenance  at  the  IMA  and  Return  of 
MRO  to  stock  can  be  found  in  the  Appendix  8.2. 


4.2.1  Information  Flows  Related  to  the  Three  Different  Maintenance 
Processes 

Table  4.1  and  Figure  4.5  show  the  information  flow  for  the  Maintenance  at  the 
Supported  Unit  and  consist  of  the  following  details: 

■  Speaker  -  Process  Originating  a  particular  communication 

■  Listener  -  The  destination  module,  where  the  information  is  received 

■  Performative  -  The  action  intended  to  be  performed  for  a  particular 
communication  between  two  nodes  [Kumara  et  al. ,  2003] 

■  Attributes  -data  elements  that  are  transferred  during  communication 

■  Medium  -  the  required  mode  of  communication  (for  example  voice,  text, 
image,  form  etc) 


38 


Integration  of  Diagnostics  into  Ground  Equipment  Study 


Final  Report 


The  above  terms  were  considered  from  speech-act  theory  and  the  Knowledge 
Query  Manipulation  Language  (KQML). 


The  information  flow  diagrams  capture  the  sequential  flow  of  information  across 
the  nodes  for  each  case.  The  tables  in  combination  with  the  information  flow 
diagrams  clearly  articulate  the  transactions  within  each  case. 
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Figure  4.5  Information  Flow  Diagram  for  Maintenance  at  the  Supported  Unit 
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4.2.2  Maintenance  Scenarios: 

A  critical  analysis  of  the  operational  architecture  shows  that  the  key  issue  for 
maintenance  is  Service  Discovery.  When  a  request  is  sent  by  a  supported  unit, 
the  requirements  such  as  manpower,  inventory  and  facilities  have  to  be  first 
identified.  Once  the  resources  are  identified  decisions  have  to  be  made  on  how 
to  optimally  utilize  them  so  as  to  fulfill  the  request.  This  leads  to  seven  possible 
events  that  have  been  identified  and  explained  in  Appendix  8.7:  IR  2/3  (Executive 
Summary  -  Pages  3-7).  Scenarios  presented  by  these  events  were  further 
refined  through  discussions  with  the  USMC  personnel. 

The  refined  scenarios  capture  the  following  USMC  organizations: 

Force  Service  Support  Group  (FSSG):  The  FSSG  performs  Intermediate  and 
limited  Depot  level  maintenance.  Limited  Depot  Level  maintenance  will  be  as 
directed  and  capable  by  the  FSSG.  This  organization  includes  inventory, 
facilities  and  manpower,  Order  Management  (OM)  team,  and  an  Expert  who 
does  resource  allocation. 

Combat  Service  Support  Element  Detachment  (CSSE  Pet):  This  organization 
includes  an  Expert  who  handles  resource  allocation,  Inventory,  Manpower, 
facilities. 

The  request  received  by  the  CSSE  Det  is  restricted  only  to  its  units  that  it 
supports,  whereas  an  FSSG  receives  a  copy  of  requests  sent  by  all  the  units. 

The  Supported  Unit  (SU):  identifies  its  requirements  and  submits  requests  to 
the  CSSE  Det  and  FSSG 


Scenario:  1 


This  scenario  represents  the  case  in  which  all  the  resources  namely  manpower, 
facilities  and  inventory  are  all  available  within  the  CSSE  Det.  Figure  4.6  shows  a 
step-by-step  information  and  physical  flow  until  fulfillment. 
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Figure  4.6  Manpower,  Tools  and  Inventory  -  All  Available 
Scenario  2: 

Figure  4.7  shows  the  information  and  physical  flows  when  the  part  is  not 
available  within  the  CSSE  Det  but  is  available  at  FSSG. 


Scenario  3: 

The  scenario  in  Figure  4.8  shows  the  sequence  of  events  when  the  part  is  not 
available  at  the  CSSE  Det  and  FSSG.  The  FSSG  places  an  order  for  the  part 
and  also  broadcasts  the  request  for  the  part  to  the  neighboring  CSSE  Det.  If  the 
part  is  available  within  a  neighboring  CSSE  Det,  it  is  sent  for  fulfilling  the  request. 
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The  FSSG  replenishes  the  part  at  both  the  CSSE  Dets.  If  none  of  the  CSSE 
Dets  have  the  requested  part,  then  the  FSSG  places  an  order  for  the  requested 
part.  Once  this  part  is  procured,  it  is  sent  to  the  requesting  unit.  This  leads  to 
Scenario  4  shown  in  Figure  4.9. 


Scenario  III:  Part  available  at 
Neighboring  CSSE  del 
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Figure  4.8  Part  Available  at  the  Neighboring  CSSE  Det 


Scenario  IV:  Part  not  available 
At  Neighboring  CSSE  det 
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Figure  4.9  Part  Not  Available  at  the  Neighboring  CSSE  Det 
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4.2.3  High  Level  Systems  Implementation  View  for  IDGE: 
4.2.3. 1  Systems  Architecture  View 


The  systems  architecture  view  describes  various  subsystems  considered  and  the 
connections  among  them.  The  systems  architecture  view  may  be  used  for  many 
purposes,  including,  for  example,  making  investment  decisions  concerning  cost- 
effective  ways  to  satisfy  operational  requirements,  and  evaluating  interoperability 
improvements.  A  systems  architecture  view  addresses  specific  technologies  and 
“systems.”  These  technologies  can  be  existing,  emerging,  planned,  or 
conceptual,  depending  on  the  purpose  that  the  architecture  effort  is  trying  to 
facilitate  (e.g.,  reflection  of  the  “as-is"  state,  transition  to  a  “to-be”  state,  or 
analysis  of  future  investment  strategies). 


RDBMS 

(root,  m,i\ 

inventory  lb 
Malntrnanrr 
Information) 


Database  Interface 

Rk  h  C  bont  Applk  atio  n 

♦ 

KDHMS  1 

(Maintenance  1 
Information)  1 

Web  Client 
Application 
(Manual  Report 
for  B/D  » 

SOAP  Client 

MS  query) 

SOAP  Server 


Web  Server 


Database  Interface 


Figure  4.10  Systems  view  for  Supported  Unit  and  CSSE  Det 
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Figure  4.1 1  Systems  View  for  CSSE  Det  and  FSSG 

Figures  4.10  and  4.11  show  the  system  details  and  form  the  basis  of  the  web 
based  transactional  proof-of-concept  system  that  has  been  implemented  at  the 
Laboratory  for  Intelligent  Systems  &  Quality  (LISQ)  at  PennState.  The 
implementation  uses  an  n-tier  architecture,  which  includes 

-  the  presentation  layer 

-  the  business  logic 

-  the  data  layer 

The  details  of  the  architecture,  user  interfaces  and  database  are  described  in 
Chapter  5. 


4.3  Data  Analysis  and  Decision  Support 

As  a  first  step  in  developing  the  proof-of-concept,  the  detailed  layout  of  Scenario 
1  described  above  is  used  and  shown  in  Figures  4.12  and  4.13.  These  figures 
show  the  participating  organizations,  relevant  databases  and  interfaces  that  are 
used.  The  requests  generated  are  either  done  by  personnel  or  by  an  on-board 
condition  based  maintenance  system  on  the  LAV’s. 
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Figure  4.12  Detailed  View  for  Scenario  1--A 
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Figure  4.13  Detailed  View  for  Scenario  1--B 

Using  these  detailed  layouts  the  team  identified  the  decisions  that  need  to  be 
made  at  the  different  nodes.  The  data  that  needs  to  be  collected  at  these  nodes 
have  also  been  identified  and  are  shown  in  the  Table  4.2  below.  The  attributes 
names  within  each  table  are  self-explanatory.  These  tables  are  classified  into 
two  categories 

-  IDGE  Main:  The  main  database  for  the  IDGE  system.  It  contains  the  data 
relevant  to  all  units  across  maintenance  processes. 

IDGE  Client:  A  small  database  used  by  individual  personnel.  It  contains 
work  order  schedule  and  request  information  related  to  those  particular 
personnel. 

Table  4.2  shows  the  data  attributes  required  for  distribution  (Distributionjnfo). 
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Table  4.2:  Distribution  Information  Table  for  Main  Database 
_ Description _ 


Database  Name 

IDGE_MAIN 

Date 

Table  Name 

Distributionjnfo 

Writer 

Table  Description 

This  gives  supply  information  to  order  new  parts 

No 

Field  Name 

PK 

Type 

Size 

Description 

1 

DISTRIBUTORJD 

PK 

Distributor  In-charge  Id 

2 

WORKJDRDERJD 

PK 

(Part  distribution;  Collection  of  damaged  parts) 

3 

PRIORITY 

Priority  number  for  distribution 

4 

PER_ASSIGN_ID 

Person  assigned  for  work  order  Id 

5 

From_Loc_ld 

From  Location  Information 

6 

To_Loc_ld 

Location  Information  (from  -  to) 

7 

Work_Comp_Date 

Work  order  completion  or  part  delivery  date  (similar 
to  ECD) 

8 

VEHJd 

Vehicles  used  for  distribution  (mode  of  transport) 

9 

POCJd 

Additional  person  (if  required) 

10 

EDDJDATE 

Estimated  Delivery  Date/Time  to  notify  the 
requestor 

11 

RRD_DATE 

Required  Ready  Date  by  the  requestor 

Particulars 

The  Tables  4.3  and  4.4  shows  the  list  of  tables  that  were  made  for  IDGE  main 
and  client  database.  These  tables  can  be  found  in  the  Appendix  8.3. 
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Table  4.3:  List  of  table  for  the  IDGE_Main  Database 

Table  Name 

1  Table  Description 

Supplyjnfo 

This  table  shows  the  supply  information 
required  to  order  new  parts 

RMJnfo 

This  table  is  related  to  the  information  for  each 
request  manager  (RM) 

Repair_Request 

This  table  is  related  to  the  information  for  each 
repair  request 

Mechanicjnfo 

This  table  is  related  to  the  information  for  each 
mechanic  in  the  CSSE  Det 

Partjnfo 

This  table  is  related  to  the  information  for  each 
part 

TooIJnfo 

This  table  is  related  to  the  information  for  each 
maintenance  tool  or  facility 

Userjnfo 

This  table  is  related  to  the  task  information  for 
each  mechanic 

L  AV_B  AS  1  C_l  N  FO 

This  table  is  related  to  the  LAV  Basic 
information 

HISTORYJVIAINT 

This  table  is  related  to  the  LAV  Maintenance 
History 

Related_Part 

This  table  shows  the  relationship  between 
defect  code  and  part  code 

Related_Tool 

This  table  shows  the  relationship  between 
defect  code  and  tool  code 

Defect  Code  l nfo 

This  is  the  table  consisting  defect  code. 

Table  4.4  List  of  table  for  i 

the  IDGE  Client  Database 

Table  Name 

Table  Description 

Repair_Request 

This  table  is  related  to  the  information  for  each 
repair  request. 

Meehan  ic__Schedule 

This  table  is  related  to  the  work  order  schedule 
for  each  mechanic 

4.3.1  Decision  Making 

The  different  types  of  analysis  that  can  be  performed  on  this  data  for  supporting 
efficient  decision-making  are  shown  in  the  templates  (1-15)  below. 

The  data  collected  at  the  three  significant  nodes,  namely,  Supported  Unit,  CSSE 
Det  and  FSSG  is  used  for  further  analysis.  In  the  following  we  show  the 
templates  that  encapsulate  several  decision  points. 

Note:  Some  elements  within  the  templates/database  tables  may  require 

encryption  as  appropriate  by  the  agency.  Those  elements  will  require 
appropriate  transmission  means  such  as  using  Non-classified  Internet  Protocol 
Router  Network  (NIPRNet)  or  Sensitive  Internet  Protocol  Router  Network 
(SIPRNet). 
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1.  Supported  Unit: 

Template  1 _ 


Decision  to  be  Made: 

Prioritize  Request 

Purpose: 

To  decide  the  priority  of  request  from  the  supported  unit 

Analysis  Method: 

-  First  In  First  Out  (FIFO) 

-  Criticality  criteria 

Constraints: 

Information  related: 

Current  available  data; 

Data  need  to  be  collected 

-  LAV  Information 

-  LAV  position 

-  Request  data 

-  Defect  code 

-  Failure  part 

-  Tasks  related  to  LAV 

-  Effect  of  failure 

-  Average  repair  time 

-  Availability  of  the  Part  related 
to  failure 

-  Importance  of  LAV’s  tasks 

Next  event/Node 
Triggered: 

The  prioritized  request  orders  are  sent  to  RM  for  effective  and  swift 
decision-making 

Template  2 


Decision  to  be  Made: 

Identify  the  Defect  Code 

Purpose: 

To  identify  the  defect  code  of  unidentified  failure  including  the 
unknown  specific  failed  part 

Analysis  Method: 

-  Intelligent  Diagnosis  /  Prognosis 

-  Rule  Based  Diagnosis 

Constraints: 

Information  related: 

Current  available  data: 

Data  need  to  be  collected: 

-  LAV  Information 

-  Operation  opinion 

-  Mechanic  opinion/inspection 

-  Sensor  data  related  parts 

-  LAV  symptoms/effect 

-  Functional  failure  mode 

-  Relation  with  functions  and 
failure  parts 

-  Effects  related  sensor  data 

Next  event/Node 
Triggered: 

The  identified  defect  code  is  sent  to  RM  for  correct  maintenance 
process. 
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Template  3 


Decision  to  be  Made: 

Failure  Trend  and  Classification 

Purpose: 

To  find  the  failure  trend  and  classify  the  failure  categories 

Analysis  Method: 

-  Reliability  analysis 

-  Failure  Mode  and  Effect  Analysis  (FMEA) 

-  Data  Mining 

-  Time  series  analysis 

Constraints: 

Information  related: 

Current  available  data: 

Data  need  to  be  collected: 

-  LAV  maintenance  history 

-  Defect  code 

-  Failure  part 

-  LAV  mileage 

-  Failure  date 

-  Failure  Frequency 

-  Relation  with  failed  parts 

-  Reasons  of  failure 

-  Statistical  Analysis 

-  Parts  categories 

Next  event/Node 
Triggered: 

The  results  are  sent  to  RM,  Mechanic,  Operator,  and  Suppliers  for 
effective  maintenance 

Template  4 


Decision  to  be  Made: 

Frequency  of  Failures 

Purpose: 

To  select  the  specific  part  for  redesigning  or  considering 
improvements 

Analysis  Method: 

-  Reliability  analysis 
-FMEA 

-  Durability  test 

-  Statistical  Analysis 

Current  available  data: 

Data  need  to  be  collected: 

Constraints: 

Information  related: 

-  LAV  information 

-  Part  information 

-  BOM 

-  Repair  history  and  reasons 

-  Defect  code 

-  Failure  mileage 

-  Frequency  of  failure 

-  Relation  between  part  and 
function 

-  Part  durability  test  result 

Next  event/Node 
Triggered: 

The  frequently  failed  parts  list  is  sent  to  RM,  Mechanic,  and 

Suppliers  for  improving  the  function  and  durability  of  the  parts. 
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2.  CSSE  Pet.: 


Template  5 


Decision  to  be  Made: 

Prioritize  Maintenance  Requests  Arriving  at  the  RM 
within  the  CSSE 

Purpose: 

Requests  are  received  from  different  supported  units  and 
depending  upon  their  importance  has  to  be  prioritized  before 
sending  for  fulfillment. 

Analysis  Method: 

-  Score  based  ranking:  linear  weighted  sum  of  priority  related 
values 

-  Deadline  analyses  with  break  down  date  and  request  date. 

-  Analysis  of  mission  and  risk  values 

-  First  in  first  out  (FIFO) 

Constraints: 

Information  related: 

Current  available  data: 

Data  need  to  be  collected: 

-  Supported  unit's  information 
(Owner  ID,  Location,  etc.) 

-  Defect  code 

-  Priority  code 

-  Break  down  date 

-  Request  date 

-  Expected  required  parts  from 
defect  code 

-  Criticality  of  the  required  parts 
(Quad  mode!) 

-  Expected  required  tools  and 
facilities  from  defect  code 

Next  event/Node 
Triggered: 

Once  the  prioritization  is  done,  the  requests  are  sent  to  resource 
(manpower,  parts,  and  tools  or  facilities)  allocation  module  and 
depending  on  the  priority  they  are  taken  up  for  fulfillment. 

Template  6 


Decision  to  be  Made: 

Manpower  (Mechanic)  Scheduling  within  the  CSSE 

Purpose: 

Each  prioritized  maintenance  request  has  to  be  assigned  to  the 
proper  mechanic(s)  for  the  task  fulfillment 

Analysis  Method: 

-  Job  (maintenance  request)  assignment  model  with  constraints 

-  Resource  (manpower)  allocation  model  with  constraints 

Current  available  data: 

Data  need  to  be  collected: 

Constraints: 

Information  related: 

-  Defect  code 

-  Request  date 

-  Labor  hours 

-  Job  status 

-  Supported  unit’s  information 

-  Priority  level  of  the  request 

-  Maintenance  specialty  code  of 
the  mechanic 

-  Number  of  assigned  tasks  for 
the  mechanic 

-  Expected  required 
maintenance  specialty  from 
defect  code 

-  Expected  available  date  for  the 
mechanic 

-  Expected  labor  hours  from 
defect  code 

Next  event/Node 
Triggered: 

Once  the  manpower  is  assigned  to  the  request,  the  request  with 
information  is  sent  to  the  database  or  system  that  assigned 
mechanic(s)  can  access. 
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Template  7 


Decision  to  be  Made: 

Required  Parts  Assignment  Rule  within  the  CSSE 

Purpose: 

If  required  for  the  maintenance,  parts  (i.e.  SECREP,  consumable 
part,  or  end  item)  in  the  inventory  have  to  be  assigned  to  each 
prioritized  maintenance  request  for  the  task  fulfillment. 

Analysis  Method: 

-  Resource  (part)  allocation  model  with  constraints 

Constraints: 

Information  related: 

Current  available  data: 

Data  need  to  be  collected: 

-  Part  information 
(NSN,  Cost,  etc) 

-  Available  quantity 

-  Defect  code 

-  Maintenance  request  date 

-  Priority  level  of  the  request 

-  Criticality  of  the  required  parts 
(Quad  model) 

-  Expected  required  parts  from 
defect  code 

-  Diagnosis  result  from  the 
mechanic 

Next  event/Node 
Triggered: 

Once  the  part  is  assigned  to  the  maintenance  request,  the  request 
with  information  is  sent  to  the  database  or  system  that  part 
inventory  manager  can  access 

Template  8 


Decision  to  be  Made: 

Required  Tools  or  Facilities  Assignment  Rule  within  the 
CSSE 

Purpose: 

For  proper  maintenance  activities,  required  tools  or  facilities  in  the 
inventory  have  to  be  assigned  to  each  prioritized  maintenance 
request  for  the  task  fulfillment. 

Analysis  Method: 

-  Resource  (tools  or  facilities)  allocation  model  with  constraints 

Constraints: 

Information  related: 

Current  available  data: 

Data  need  to  be  collected: 

-Tool  (facilities)  information 

-  Available  quantity 

-  Defect  code 

-  Maintenance  request  date 

-  Priority  level  of  the  request 

-  Required  tools  and  facilities 
from  defect  code 

-  Required  available  date  for  the 
tool  or  facility 

-  Number  of  requests  that  are 
waiting  to  use  the  tool  or  facility 

Next  event/Node 
Triggered: 

Once  the  tools  or  facilities  are  assigned  to  the  maintenance 
request,  the  request  with  information  is  sent  to  the  database  or 
system  that  tool  or  facility  inventory  manager  can  access. 
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Template  9 


Decision  to  be  Made: 

Forecasting  Maintenance  Requests  Arriving  at  the  RM 
within  the  CSSE 

Purpose: 

Based  on  the  history  of  maintenance  requests  received  from 
different  supported  units,  trends  can  be  analyzed  Furthermore,  it 
will  be  possible  to  predict  or  forecast  maintenance  request  arrivals 

Analysis  Method: 

-  Time  series  model 

-  Data  mining:  pattern  analysis,  classification 

Constraints: 

Information  related: 

Current  available  data: 

Data  need  to  be  collected: 

-  Supported  unit’s  information 

-  Defect  code 

-  Priority  code 

-  Maintenance  request  date 

-  Break  down  date 

-  Priority  level  of  the  request 

-  MTBF 

-  Average  required  time  for  the 
maintenance 

Next  event/Node 
Triggered: 

Once  the  maintenance  request  forecasting  or  trend  analysis  is 
done,  the  result  can  be  sent  to  supervisors  and  operators  in 
supported  units,  resource  (manpower,  parts,  and  tools)  managers, 
and  OM  (order  manager)  and  FM  (financial  manager)  in  FSSG  for 
efficient  planning. 

Template  10 


Decision  to  be  Made: 

Manpower  (Mechanic)  Planning  within  the  CSSE 

Purpose: 

Based  on  the  history  of  maintenance  requests  received  from  the 
different  supported  units  and  analysis  of  history  of  manpower 
scheduling,  it  is  possible  to  perform  better  manpower  planning  and 
to  forecast  manpower  requirement. 

Analysis  Method: 

-  Time  series  model 

-  Dynamic  programming  model 

Constraints: 

Information  related: 

Current  available  data: 

Data  need  to  be  collected: 

-  Supported  unit's  information 

-  Defect  code 

-  Priority  code 

-  Maintenance  request  date 

-  Priority  level  of  the  request 

-  MTBF 

-  Expected  labor  hours  for  the 
maintenance 

-  Average  required  maintenance 
specialty  code  of  the  mechanic 

-  Average  number  of  assigned 
tasks  for  the  mechanic 

Next  event/Node 
Triggered: 

Once  the  manpower  (mechanic)  planning  analysis  is  done,  the 
result  can  be  sent  to  RM  or  manpower  scheduling  module,  and  FM 
(financial  manager)  in  FSSG  for  increasing  the  performance  of 
maintenance  request  fulfillment. 
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Template  11 


Decision  to  be  Made: 

Part  Inventory  Planning  within  the  CSSE 

Purpose: 

Based  on  the  history  of  maintenance  requests  received  from  the 
different  supported  units  and  analysis  of  history  of  part  assignment, 
it  is  possible  to  perform  better  part  inventory  planning  and  to 
forecast  part  requirement. 

Analysis  Method: 

-  EOQ  (Economic  Order  Quantity)  model 

-  Time  series  model 

-  Dynamic  programming  model 

Constraints: 

Information  related: 

Current  available  data: 

Data  need  to  be  collected: 

-  Part  information 
(NSN,  Cost) 

-  Available  quantity 

-  Defect  code 

-  Maintenance  request  date 

-  Priority  level  of  the  request 

-  MTBF 

-  Criticality  of  the  required  parts 
(Quad  model) 

-  Expected  required  parts  from 
defect  code 

-  Diagnosis  result  from  the 
mechanic 

-  Average  number  of  parts  used 
in  specific  time  period 

Next  event/Node 
Triggered: 

Once  the  part  inventory  planning  analysis  is  done,  the  result  can  be 
sent  to  RM,  part  inventory  manager,  and  OM  (order  manager)  and 

FM  (financial  manager)  in  FSSG  for  increasing  the  performance  of 
maintenance  request  fulfillment. 
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3.  FSSG: 


Template  12 


Decision  to  be  Made: 

Inventory  Planning  within  the  FSSG 

Purpose: 

Based  on  the  history  of  maintenance  requests  received  from  the 
different  supported  units  and  the  current  conditions  of  the  LAV 
within  its  supervision  the  FSSG  can  predict  the  demand  for  various 
parts  for  the  next  specified  time  window 

Analysis  Method: 

-  EOQ  (Economic  Order  Quantity)  model 

-  Time  series  model 

-  Dynamic  programming  model 

-  Bayesian  Statistical  Model 

Constraints: 

Information  related: 

Current  available  data: 

Data  need  to  be  collected: 

-  Part  information 
(NSN,  Cost) 

-  Available  quantity 

-  Defect  code 

-  Maintenance  request  date 

-  Priority  level  of  the  request 

-  MTBF 

-  Criticality  of  the  required  parts 
(Quad  model) 

-  Expected  required  parts  from 
defect  code 

-  Diagnosis  result  from  the 
mechanic 

-  Average  number  of  part  used 
in  specific  time  period 
-Distribution  showing  the  failures 
with  time 

Next  event/Node 
Triggered: 

Once  the  part  inventory  planning  analysis  is  done,  the  result  can  be 
sent  to  OM,  Inventory  Capacity  manager,  and  FM  (financial 
manager)  in  FSSG  for  increasing  the  performance  of  maintenance 
request  fulfillment. 
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Template  13 


Decision  to  be  Made: 

Budget  Estimation 

Purpose: 

Analyzing  the  historical  data  to  identify  the  mean  time  between 
failures  for  different  NSN  will  allow  the  FM  to  estimate  the  number 
of  expected  failures  within  a  subsystem.  Based  on  the  previous 
repair  costs  incurred  and  the  cost  of  parts  that  will  be  used  the 
approximate  budget  that  will  be  required  can  be  estimated 

Analysis  Method: 

-  Bayesian  Statistical  models 

-  Time  series  model 

-  Dynamic  programming  model 

Constraints: 

Information  related: 

Current  available  data: 

Data  need  to  be  collected: 

-  Repair  costs 

-  Defect  code 

-  Maintenance  request  date 

-  Priority  level  of  the  request 

-  MTBF 

-  Miles  of  operations  of  different 
LAVs 

-  Average  time  for  repair  of  each 
defect  code 

-  Average  number  of  parts  used 
in  specific  time  period 

Next  event/Node 
Triggered: 

Once  the  budget  estimation  analysis  is  done,  the  results  can  be 
sent  to  FM,  and  personnel  in  the  strategic  level  to  estimate  overall 
budget  required  towards  maintenance  for  the  next  planning  horizon. 
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Template  14 


Decision  to  be  Made: 

i 

Training  Decisions  for  Mechanics 

Purpose: 

Using  the  frequency  of  failures  within  a  subsystem  and  the  labor 
hours  spent  to  repair  each  of  these  subsystems,  the  high  risk 
maintenance  repairs  can  be  identified.  These  inferences  can 
determine  the  specific  maintenance  areas  where  training  and 
facilities  can  be  improved 

Analysis  Method: 

Statistical  models 

Meta  Heuristics 

Current  available  data. 

Data  need  to  be  collected: 

Constraints: 

Information  related: 

-  Part  information 
(NSN,  Cost) 

-  Labor  Hours 

-  Defect  code 

-  Maintenance  request  date 

-  Priority  level  of  the  request 

-  MTBF 

-  Expertise  of  the  mechanic 
performing  the  repair  on  each 
subsystem 

-  Average  time  for  repair  for 
given  subsystem 

-  Number  of  times  there  is 
misdiagnosis  by  the  mechanic/ 
operator. 

-  Delays  due  to  unavailability  of 
facilities 

Next  event/Node 
Triggered: 

Once  this  analysis  is  done,  the  strategic  level  personnel  to 
determine  the  bottleneck  maintenance  operations  can  use  the 
results.  Depending  on  the  expertise/experience  of  the  mechanics 
currently  within  the  organization,  training  can  be  planned  and 
facilities  can  be  improved 
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Template  15 


Decision  to  be  Made: 

Prioritizing  the  Requests 

Purpose: 

Based  on:  1  The  Field  activity  designator,  2.  The  urgency  of  need 
indicated  by  the  requesting  unit  and  3.  The  next  move  for  the  unit, 
the  operational  level  commanders  can  prioritize  the  arriving 
requests. 

Analysis  Method: 

Ranking  based  on  scores 

Analysis  of  mission  value 

First  in  first  Out 

Expected  date  of  delivery 

Constraints: 

Information  related: 

Current  available  data: 

Data  need  to  be  collected: 

-  Supported  unit’s  information 
(Owner  ID,  Location,  etc.) 

-  Defect  code 

-  Priority  code 

-  Break  down  date 

-  Request  date 

-  Effect  of  failure 

-  Average  repair  time 

-  Availability  of  Parts 

-  Importance  of  units  tasks 

-  Availability  of  manpower 

Next  event/Node 
Triggered: 

Once  the  requests  are  prioritized  they  can  be  executed  for 
fulfillment  in  the  order  of  importance.  This  will  ensure  fair  allocation 
of  resources  by  speedy  execution  of  high  priority  requests. 
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5  Universal  Data  Support  Requirements 

Task  4:  Establish  Universal  Data  Support  Requirements. 

•  Task  4.1:  Identify  data  support  functions  for  multi-sensor  prognostics  integration 
for  the  selected  end  item. 

•  Task  4.2:  Recommend  candidate  web  based  technologies  to  facilitate  multi¬ 
sensor  prognostic  integration  for  the  selected  end  item. 

This  chapter  contains  the  initial  templates  developed  by  the  PSU  team  for  multi 
sensor  diagnostics/prognostics,  and  the  architecture  for  the  IDGE  web  based 
maintenance  system. 

5. 1  Establish  Universal  Data  Support  Requirements. 

5.1.1  Initial  Templates  for  Implementing  Multisensor  Diagnostics 

A  goal  of  this  study  was  to  establish  templates  that  can  apply  to  any  piece  of 
ground  equipment  with  a  standard  means  to  deploy  diagnostics/prognostics, 
track,  evaluate,  anticipate  failure,  activate  the  supply/maintenance  system  to 
request,  order  and  repair  the  item  based  upon  varying  time  constraint  scenarios. 
In  this  section,  we  present  initial  templates  that  show  how  to  implement  multi¬ 
sensor  diagnostics  for  a  chosen  type  of  equipment.  These  templates  use  the  LAV 
as  the  chosen  example.  However,  the  templates  can  be  used  for  other  types  of 
equipment. 


Template  1 


Decision  to  be  Made: 

Identification  of  Top  Faults/Conditions  to  be  Monitored 

Purpose: 

To  determine  the  top  candidates  of  faults  and/or  conditions  for 
monitoring  the  condition  of  the  chosen  equipment 

Analysis  Method: 

•  Encapsulate  functions  to  be  performed  by  the  equipment 

•  Analyze  MIMMS  data 

•  Interviews  with  users,  maintainers,  and  decision-makers 

Information  Needed  / 
Constraints: 

•  Vehicle  identity  information 

•  Vehicle  location  information 

•  Vehicle  task  /  mission  information 

•  Typical  events  in  vehicle  life  cycle 

•  Criticality  of  failure,  i.e.,  effect  /  cost  of  failure 

•  Maintenance  cost  /  support  required 

•  Frequencies  at  which  faults  /  conditions  have  been 
observed 

•  Component  reliability  /  expected  life  information 

Next  event/Node 
Triggered: 

Sensor  Selection  and  Placement. 
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Template  2 


Decision  to  be  Made: 

Sensor  Selection  and  Placement 

Purpose: 

To  decide  the  sensor  suite  and  the  optimum  placement  of  sensors 
for  monitoring  faults/conditions  for  chosen  equipment 

Analysis  Method: 

•  Failure  Modes,  Effects,  and  Criticality  Analysis  (FMECA) 

•  Physics-based  modeling  of  system  hierarchy 

•  Identify  cause-effect  relationship  for  each  fault  /  condition 

Information  Needed  / 
Constraints: 

•  Vehicle  system,  subsystem,  component,  material  hierarchy 

•  Differences  among  vehicle  variants 

•  Estimated  loads  to  be  experienced  by  the  vehicle 

•  Environmental  influences  on  vehicle  operation 

•  Criticality  of  failure,  i  e  ,  effect  /  cost  of  failure 

•  Availability  of  sensors  and  their  quality  /reliability 

•  Assess  limitations  on  power,  number,  and  operational 
mode  of  sensors 

•  Constraints  on  ability  to  place  sensors 

Next  event/Node 
Triggered: 

Selection  of  Data  Analysis  Methods  for  processing  Sensor  Data 

Template  3 


Decision  to  be  Made: 

Selection  of  Data  Analysis  Methods  for  Processing 

Sensor  Data 

Purpose: 

To  select  the  data  analysis  methods  for  analyzing  sensor  data  for 
monitoring  faults/conditions  for  chosen  equipment 

Analysis  Method: 

•  FMECA 

•  Mapping  of  cause-effect  relationship  into  observables 

•  Examine  the  correlation  between  different  causes  and 
effects 

Information  Needed  / 
Constraints: 

•  Vehicle  operational,  maintenance,  historical  data 

•  Sensor  types,  number,  and  locations 

•  Sensor  performance  information 

•  Physics-based  model  of  system  hierarchy 

•  Cause-effect  relationship  for  each  fault  /  condition 

Next  event/Node 
Triggered: 

Architecture  and  Algorithm  Selection  for  Processing  Sensor  Data. 
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Decision  to  be  Made: 

Architecture  and  Algorithm  Selection  for  Processing 
Sensor  Data 

Purpose: 

To  select  the  architecture  and  the  algorithms  for  processing  sensor 
data 

Analysis  Method: 

•  Centralized,  distributed,  or  hybrid  processing  comparison 

•  Analytical  modeling  methods 

•  Statistical  signal  processing  techniques 

Information  Needed  / 
Constraints: 

•  Hierarchical  description  of  system 

•  Bandwidth  and  throughput  of  transmission  mechanisms 

•  Formats  and/or  protocols  pertaining  to  existing  network 
components 

•  Availability  space,  wiring,  and  power 

Next  event/Node 
Triggered: 

Selection  of  Data  Collection  and  Data  Processing  Hardware  and 
Software 

Decision  to  be  Made: 

Selection  of  Data  Collection  and  Data  Processing 

Hardware  and  Software 

Purpose: 

To  select  the  data  collection  hardware  and  data  processing 
hardware  and  software 

Analysis  Method: 

•  Mapping  of  techniques  to  appropriate  hardware 

•  Speed,  power,  and  cost  comparison 

•  Information  needed  for  various  algorithms 

•  Features  required  for  fault  classification 

Information  Needed  / 
Constraints: 

•  Bandwidth  and  throughput  of  transmission  mechanisms 

•  Formats  and/or  protocols  pertaining  to  existing  network 
components 

•  Availability  and  supportability  of  hardware  and  software 
options 

•  Cost  of  implementation 

•  Availability  space,  wiring,  and  power 

•  Environmental  requirements  (e  g.,  vibration,  corrosive 
fumes,  high  temperature,  etc.) 

Next  event/Node 
Triggered: 

Determination  of  Data  Collection  Rates  and  Formats. 
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Template  6 


Decision  to  be  Made: 

Determination  of  Data  Collection  Rates  and  Formats 

Purpose: 

To  estimate  the  rates  at  which  data  will  be  collected  from  various 
sensors;  to  define  the  data  formats  for  archiving  and 
communicating  the  data  collected  and  analyzed 

Analysis  Method: 

•  Physical  analyses  of  failure  propagation 

•  Time  intervals  required  for  supporting  maintenance  and 
logistical  response 

•  Complexity  analysis  of  algorithms 

•  Information  requirement  of  algorithms 

Information  Needed  / 
Constraints: 

•  Bandwidth  and  throughput  of  transmission  mechanisms 

•  Formats  and/or  protocols  pertaining  to  existing  network 
components 

•  Computation  speed  and  throughput  of  selected  hardware 
and  software 

•  Time  intervals  required  for  supporting  maintenance  and 
logistical  response 

Next  event/Node 
Triggered: 

Software  Implementation  and  Test  and  Validation. 

These  are  followed  by  software  implementation  of  the  algorithms  and  testing  and 
validation  of  the  implementation. 


5.2  Proposed  System  Architecture:  n-tier  Web-based 
Architecture 

5.2.1  High  Level  Architecture 


The  futuristic  IDGE  maintenance  information  system's  requirements  are: 

■  Information  brokerage  tools  capable  of  providing  instantaneous, 
automated  access  to  all  information  required  as  inputs  to  decisions  or 
analysis  questions. 

■  Decision  making  algorithm  routines  (i.e.,  quad  model  and  data  mining 
etc.). 

■  Analysis  and  sensor  signal  processing  tools  to  process  current  or 
historical,  real  or  simulated  data. 

■  Collaborative  planning  tools  that  enable  decision-makers  in  separate 
hierarchies  or  organizations  (CSSE  Dets,  FSSG  etc)  to  communicate 
efficiently,  share  data,  and  jointly  edit  files  and  run  programs  to  arrive  at 
coordinated  decisions  visible  to  all  processes  involved. 
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■  Historical  data  (e.g.,  Maintenance  request,  manpower  requirement,  part 
requirement,  and  so  on)  -  data  storage  can  be  resident  either  in  a 
centralized  or  distributed  fashion  and  can  be  accessed  via  information 
brokerage  tools. 

■  Security  software,  hardware,  and  protocols  to  ensure  proper  access  and 
restrict  improper  access  to  all  system  hardware,  software,  and  information. 

■  User-friendly  graphical  user  interfaces  (GUIs)  to  control  all  software, 
information  retrieval,  reporting,  and  collaboration. 

■  On-line  Help,  Training,  and  Process  and  Software  Documentation  are 
required  to  maximize  the  productivity  of  system  user  and  the  quality  of  all 
decisions. 

In  this  context,  the  term  "architecture"  refers  to  the  software  and  hardware 
system  configuration  for  accomplishing  the  objective  of  maintenance  information 
system.  This  is  a  high-level  architecture;  by  definition,  the  individual  software 
components  must  be  expanded  to  make  each  of  them  fully  functional.  Our 
recommendation  will  serve  as  a  blueprint  for  the  Marine  Corps  implementation  of 
a  futuristic,  fully  functional,  flexible  and  integrated  ground  equipment  system. 

The  proposed  architecture  will  have  the  following  characteristics: 

■  Reduced  query  retrieval  time  from  databases 

■  Timeliness  of  information  at  decision-making  points 

■  Ease  of  updating  databases 

■  Ease  of  adding  new  applications 

■  Ease  of  updating  existing  applications 

■  Ease  of  reconfiguring  to  support  organizational  changes  within  the  USMC 

■  Cost  savings  in  terms  of  money,  time,  and  manpower 

■  System  robustness  (eliminate  problems  caused  by  data  inconsistencies) 

■  Information  visualization 

■  Decision  making,  analyzing,  and  forecasting  capabilities 

■  Platform  independence 

5.2.2  n-tier  Web-based  Architecture 

We  recommend  an  n-tiered  architecture  that  allows  for  scalability, 
reconfigurability,  and  flexibility.  Our  proposed  architecture  is  a  viable  solution  to 
realize  the  knowledge  management  architecture  envisioned  by  the  Marine  Corps. 
Furthermore,  large  commercial  enterprise  systems  such  as  System  Application 
Product  (SAP)  R/3,  PeopleSoft,  and  Oracle  employ  such  n-tiered  architectures. 
Figure  5.1  shows  the  highest  level  of  abstraction  of  the  proposed  architecture. 
Although  this  diagram  specifically  shows  three  tiers,  the  architecture  can  have  n 
tiers,  with  n  determined  through  the  sub-process  decomposition. 
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Figure  5.1  System  Architecture 

The  various  components  of  the  architecture  are: 


o  Application 
o  Database 

o  Graphical  User  Interface  (GUI) 
o  Hardware 
o  Security 
o  Analysis 

o  Help/Documentation/Training 

5. 2. 2.1  Application 


Application  refers  to  the  computational  model  (software  +  algorithms)  for  each  of 
the  processes  and  sub-processes  identified.  The  software  components 
(applications)  each  will  have  inter-application  communication,  database  interface, 
and  a  graphical  user  interface.  This  definition  of  application  is  consistent  with  the 
terminology  used  in  database  literature.  Our  configuration  of  the  architecture  will 
allow: 


■  Interactivity 

■  Plug-and-play  functionality 

■  Functional  independence 

■  Platform  independence 


5. 2. 2. 2  Database 

To  address  the  need  for  distributed  control  of  information  and  to  ensure 
adaptability  to  future  reorganizations,  we  separated  the  databases,  applications, 
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and  graphical  user  interfaces  (GUIs)  in  our  architecture.  This  provides  flexibility, 
adaptability,  and  scalability.  A  generic  interface  for  each  data  source  will  be  used 
by  all  applications  that  require  access  to  the  data  source.  Like  other  applications, 
these  interfaces  will  support  varying  levels  of  access  and  other  security 
measures.  Information  Brokerage  tools  will  be  used  to  facilitate  access  to  the 
wealth  of  data  that  is  used  at  present  due  to  a  lack  of  awareness  by  the  user 
community.  Although  several  database  technologies  (e.g.,  Informix,  Microsoft, 
and  SyBase)  exist,  Oracle  offers  a  number  of  advantages.  A  robust  database,  it 
is  one  of  the  few  systems  that  can  fully  benefit  from  parallelism  and  server 
clusters. 


5. 2. 2. 3  Graphical  User  Interface  (GUI) 

The  GUI  is  the  interface  between  the  user  and  the  applications.  GUIs  can 
customize  information  content  and  presentation  to  the  needs  and  abilities  of  the 
user.  The  proposed  architecture  will  have  the  web  browser  GUIs. 

It  is  envisioned  as  a  browser-based  interface  that  will  enhance  the  customization 
required  and  will  help  in  visualization  of  the  user  elements  required.  The  GUI’s 
HTML  compatibility  will  enable  users  to  open  it  within  any  common  web  browser 
such  as  Netscape  or  Internet  Explorer.  This  will  allow  software  upgrades  to  be 
administered  efficiently  because  user  software  does  need  to  change.  The 
following  approach  was  developed. 


5. 2. 2. 4  Hardware 

The  required  computer  hardware  can  be  specified  for  each  application  (or  group 
of  applications),  based  on  algorithmic  complexities,  user  loads,  and  other 
variables.  This  naturally  leads  to  a  cluster  approach  to  building  the  network 
topology.  Figure  5.2  shows  the  proposed  candidate  hardware  architecture. 
Recognizing  the  rapidly  changing  nature  of  the  hardware  market,  we  specified 
conceptual  hardware,  rather  than  exact  model  numbers.  The  recommended 
cluster  is  a  group  of  symmetric  multi  processor  (SMP)  servers  over  a  Gigabit 
network  using  the  Virtual  Interface  Architecture  (VIA).  VIA  is  a  cost-effective 
scaling  of  computing  hardware.  We  further  recommend  that  each  application  be 
provided  with  an  SMP  server  (4-way  or  8-way)  sized  to  fit  the  expected 
computing  load.  The  Oracle  database  can  be  a  limiting  factor  in  responsiveness 
of  the  overall  architecture;  therefore,  we  recommend  that  the  database  be 
partitioned  on  a  cluster  to  speed  up  query  processing  through  parallelization  and 
distribution  of  computing.  Furthermore,  Oracle  is  one  of  few  software  programs 
that  can  effectively  exploit  parallel  query  processing  on  SMP  clusters.  This  would 
be  the  ideal  configuration. 
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Figure  5.2  Candidate  Hardware  Architecture 


5. 2. 2. 5  Security 

The  three  components  of  the  system  architecture  are  software,  hardware,  and 
people.  Securing  the  computer  system  involves  ensuring  the  security  of  the 
software  and  hardware,  as  well  as  the  trustworthiness  of  the  people  who  use  it. 
For  the  proposed  architecture,  key  security  aspects  can  be  broken  down  as 
follows: 

■  Application-Level  and  User-Level  Security 

■  Internet  and  Intranet  Security 

■  Access  Control 

5. 2.2. 6  Analysis 

Considerable  data  will  be  generated  through  various  decision-makings  and 
forecasting.  Analysis  will  depend  on  the  context  and  what  is  needed  in  the 
context.  Several  visualization  algorithms  for  displaying  trends  and  patterns  can 
be  incorporated  into  the  architecture.  More  advanced  data  mining  algorithms  like 
sequential  pattern  analyzer,  neural  networks,  and  adaptive  clustering  can  easily 
be  incorporated  into  the  architecture.  Analysis  software  will  be  sub-applications  in 
the  system. 


5. 2. 2. 7  Help/Documentation/Training 

These  help  sessions  will  be  available  on  request  or  on  trigger  by  events 
(monitoring  of  user  activities).  Appropriate  computer-assisted  instruction  (CAI) 
based  GUIs  will  be  suggested  and  the  architecture  will  incorporate  on-line  help. 
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5.3  Database  Model  Diagram 

This  diagram  shows  the  connectivity  between  elements  of  the  tables  listed  in  the 
Table  5.1. 

Table  5.1  Database  Model  Diagram 
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5.4  Proof-of-Concept  Maintenance  Information  System  -  A 
Conceptual  View 

One  of  the  most  important  aspects  of  our  design  is  the  ease  of  use  of  the 
proposed  computing  system  for  the  maintenance  request  fulfillment.  This 
proposed  architecture  has  GUI,  which  enables  the  user  (RM  or  other  users)  to 
query  the  required  information  from  the  database,  to  perform  related  tasks  for  the 
maintenance  fulfillment,  and  to  analyze  the  data.  This  information  is  then  stored 
in  the  database  for  future  retrieval  processes  /analysis. 

In  this  section  we  (1)  present  how  a  user  can  navigate  through  the  proposed 
maintenance  information  system  and  (2)  illustrate  the  major  features  of  our 
proposed  architecture. 

Our  hypothetical  user,  RM,  performs  the  tasks  in  this  animation.  In  the  real 
system,  some  of  the  tasks  will  be  performed  by  other  users  and/or  software 
agents  representing  the  other  users. 

The  GUI’s  shown  in  Figure  5.3  are  relevant  to  the  Request  Management.  The 
team  is  currently  working  to  generate  similar  GUI’s  for  Supervisor  at  the  tactical 
level  and  FSSG. 
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Figure  5.3  Process  Flow  Overview  -  Web  Based  System 
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Main  Window:  Figure  5.4  shows  the  Main  Window  for  the  Proof-of-concept  web- 
based  system. 
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Figure  5.4  Main  Windows 

The  users  can  log  on  into  the  system  using  their  userid  and  password  as  shown 
in  Figure  5.5 


Figure  5.5  Login  Windows 

Once  the  user  logs  onto  the  system  he  or  she  is  informed  the  details  of  the  last 
login  session.  Depending  on  the  MOS  and  responsibility  of  the  particular  user  he 
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is  presented  with  the  appropriate  menu  options.  The  Figure  5.6  shown  below 
presents  the  layout  for  a  Request  Manager  within  a  CSSE  Det. 


Figure  5.6  Request  Manager  Window  within  a  CSSE  Det 


The  request  Manager  will  be  able  to  view  the  requests  that  have  been  received. 
The  system  also  shows  the  current  status  of  these  requests  (Figure  5.7).  The 
request  manger  can  view  the  detailed  information  for  a  particular  request  as 
shown  in  Figure  5.8. 
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Figure  5.7  Request  Status  Windows 
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Figure  5.8  Detailed  Information  for  the  Request 


When  the  request  manager  clicks  the  button  to  allocate  resources  for  a  particular 
request,  a  software  agent;  queries  the  relevant  databases  for  the  availability  of 
resources.  These  are  passed  onto  the  scheduling  algorithm  that  makes 
schedules  and  allocates  resources  optimally  in  order  to  fulfill  the  request.  The 
resulting  information  is  presented  as  shown  below  in  Figure  5.9. 
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Figure  5.9  Request  Assignment  Windows 

The  request  manager  can  also  query  the  current  status  of  the  different 
mechanics  within  the  particular  CSSE  Det.  He  or  She  can  also  click  the  link  to 
obtain  detailed  information  about  a  particular  mechanic  as  shown  in  Figures  5.10 
and  5.11. 


Figure  5.10  Mechanic  (Manpower)  Status  Window-A 
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Figure  5.11  Mechanic  (Manpower)  Status  Windows-B 


The  request  manager  can  view  the  information  regarding  the  status  of  parts 
(NSN)  internally  available  within  the  CSSE  Det  as  shown  in  Figure  5.12. 
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Figure  5.12  Part  Inventory  List  Window 
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The  detailed  information  for  a  particular  NSN  as  shown  in  Figure  5.13  can  also 
be  viewed. 


Figure  5.13  Detailed  Part  Information  Window 


The  request  manager  can  analyze  the  history  of  requests  that  he/she  has 
received.  Each  type  of  request  and  its  corresponding  frequency  are  shown  in 
Figure  5.14  after  the  analysis  agent  queries  the  request  history  database  and 
generates  the  results. 
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Figure  5.14  Analyses  for  the  Type  of  Request  and  its  Frequency 
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6  Critical  Paths  and  Risks 

Task  5:  Identify  Critical  Path  and  Risks  for  One  (1)  Candidate  System.  Interpret  and 
correlate  the  results  of  tasks  1-4  and  depict/present  the  information  in  a  way  that 
identifies  a  critical  path  for  implementation  of  a  USMC  Autonomic  Logistics  Support 
System  by  FY  2008. 


6.1  Integration  Issues 

Integration  of  both  applications  and  databases  has  been  an  ongoing  problem  in 
today’s  commercial  world.  Several  industries,  academicians  and  non-profit 
research  organizations  are  developing  novel  techniques  for  integrating  entire 
systems,  developed  on  different  platforms,  across  an  enterprise.  The  issue  of 
integration  becomes  prominent  when  an  organization  is  planning  to  transform  its 
information  technology  infrastructure  and  operating  policies.  The  integration  of 
diagnostics  to  ground  equipment  and  the  concept  of  autonomic  logistics  demand 
a  host  of  new  systems  that  need  to  be  developed.  Depending  on  the  budget 
constraints  and  organizational  issues  the  USMC  might  replace  some  or  all  of  the 
legacy  systems.  Since  the  envisioned  systems  are  transactional  in  nature  and 
will  provide  visibility  of  assets  and  operations  across  the  USMC,  they  need  to  be 
tightly  integrated.  The  migration  to  this  new  set  of  systems  will  pose  challenges  if 
either  all  or  few  of  the  legacy  systems  are  replaced. 

Migration  could  be  through  two  different  methods  -  one  is  to  build  an  entirely  new 
infrastructure  the  other  would  be  replace  only  some  of  the  legacy  systems.  In 
both  these  cases  integration  issues  arise.  In  the  first  case,  the  USMC  needs  to 
ensure  that  the  data  currently  available  is  transferred  from  the  legacy  systems  to 
the  newly  developed  system.  Currently  this  cannot  be  achieved  through 
automated  means.  The  difference  in  database  schema  between  the  legacy  and 
new  systems  will  cause  difficulty  for  data  migration.  Though  the  migration  can  be 
achieved  through  semi-automated  or  manual  means  these  methods  are  error 
prone  and  tedious.  Therefore  the  existing  database  has  to  be  clearly  mapped  to 
the  schema  that  will  be  used  in  future  systems.  Most  industries  today  are 
adopting  the  XML  schema  for  specifying  data.  This  being  an  emerging  standard 
need  to  be  used  in  the  future  logistics  systems  that  will  be  developed. 

In  the  case  where  both  legacy  and  future  systems  will  be  in  place,  the 
applications  that  will  be  developed  for  the  future  need  to  access  the  data  from 
both  these  databases.  Owing  to  the  difference  in  the  type  of  interfaces  that  these 
databases  present,  a  number  of  application  program  interfaces  will  have  to  be 
developed  so  as  keep  the  system  integrated.  Another  method  will  be  to  wrap  the 
legacy  systems  and  interface  the  wrappers  with  the  new  development. 

In  the  context  of  maintenance  and  CBM  the  sensor  signals  and  the  related 
diagnostics/prognostics  information  have  to  be  stored  and  integrated  with 
logistics  systems.  This  would  be  a  challenge  as  the  type  of  database  architecture 

80 


Integration  of  Diagnostics  into  Ground  Equipment  Study 


Final  Report 


and  schema  that  is  used  to  store  sensor  signal  data  and  that  of  enterprise 
systems  differ  considerably.  Most  current  day  health  monitoring  systems  are  not 
tied  in  with  the  logistics  systems.  This  needs  to  be  achieved  in  order  to  enable 
the  concept  of  autonomic  logistics. 

Critically  analyzing  the  current  day  technologies  show  that  the  future  web  based 
applications  have  to  be  enabled  with  sufficient  metadata  that  need  to  be 
compliant  with  XML  specifications.  Most  data  integration  and  schema  matching 
tools  that  are  developed  today  assume  XML  data  and  so  using  this  approach  will 
ensure  easy  migration  of  information  between  systems  in  future.  A  Review  on 
Enterprise  Application  Integration  (EAI)  has  been  documented  in  Appendix  8.6:IR 
1:  Appendix  9,  Pages  181-187. 


6.2  Distributed  vs.  Centralized  Signal  Processing 

The  envisioned  IDGE  system  requires  sensors  to  be  placed  onboard  the  ground 
equipment.  The  sensor  signals  detected  from  these  sensors  can  be  processed 
onboard  or  sent  to  a  centralized  signal  data  repository  for  analysis.  Owing  to  the 
highly  dynamic  environment  and  high  mobility  of  the  ground  equipment  a 
distributed  sensor-processing  paradigm  is  more  suitable  for  the  IDGE  system. 
Each  end  item  will  have  to  process  the  signals  generated  by  the  sensors  and 
detect  anomalies,  the  inferences  that  is  made  through  sensor  processing  is  then 
transmitted  to  the  relevant  nodes  (RM)  in  the  form  of  a  request.  The  use  of  a 
distributed  computing  paradigm  requires  a  number  of  additional  functionalities 
within  the  end  items,  such  as  sufficient  processing  power,  appropriate  memory 
capacity  and  most  importantly  connectivity.  The  templates  that  have  been 
developed  in  this  study  can  be  applied  to  different  end-items,  but  a  constant 
connectivity  with  the  RM  nodes  is  required  throughout  the  operation  of  the 
vehicles.  The  requirements  for  enabling  such  communication  are  described  in  the 
next  section. 


6.3  Communication  Load 

An  analysis  of  the  data  generated  and  used  by  the  use  cases  i.e.  transmitted 
across  different  levels  of  the  infrastructure  has  been  completed.  The  process 
followed  for  this  was  described  in  Section  4.1.5  and  the  results  of  the  aggregated 
data  requirements  are  shown  in  Appendix  8.4.2.  As  expected,  these  results 
indicate  that  the  bulk  of  the  communication  is  likely  to  occur  between  the  vehicle 
and  the  O-level.  A  caveat  in  interpreting  these  results  is  that  the  frequencies 
estimated  for  these  use  cases  were  obtained  from  potential  users,  who  indicated 
that  these  should  be  considered  tentative.  Before  infrastructure  decisions  can  be 
made  based  on  this  analysis  of  communication  load,  it  is  necessary,  therefore,  to 
further  validate  these  either  via  simulation  or  by  corroborating  them  with 
additional  input  from  a  larger  set  of  users.  A  second  caveat  is  that  these 
aggregated  data  transmission  results  do  not  reveal  any  burst  nature  of 
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communication  that  may  be  required.  These  can  be  identified  to  further 
characterize  the  communication  load  across  different  levels  of  the  infrastructure. 


6.4  Unique  Military  Considerations  and  Survivability 

The  primary  consideration  for  deployed  operations  is  to  be  able  to  gather 
information  about  the  health  of  the  ground  equipment  in  real-time  and  trigger  the 
relevant  maintenance  actions.  The  IDGE  system  relies  on  the  communication 
network  to  transmit  the  information  gathered  by  the  sensors.  The  reliability  of  the 
communication  network  will  therefore  play  an  important  role  in  the  efficient 
functioning  of  the  IDGE  system.  It  must  be  noted  that  sufficient  redundancy  has 
to  be  built  into  the  communication  network  so  that  ground  equipment  have 
alternate  means  to  communicate  their  health  information  to  the  relevant  nodes 
within  the  operational  architecture.  In  addition  we  recommend  that  I/O  port  be 
built  into  the  onboard  system  so  that  in  the  absence  of  communication  channels 
the  maintenance  personnel  can  collect  the  relevant  data  by  connecting  the  hand 
held  devices  to  the  I/O  ports. 


6.5  Transition  Plans 

Transition  plans  for  a  proposed  IDGE  system  can  be  identified  in  at  least  three 
directions. 

First,  we  recommend  that  an  incremental  strategy  be  employed  for  implementing 
a  proposed  IDGE  system.  The  incremental  strategy  can  be  operationalized  in 
several  ways.  Clearly,  some  platforms  may  be  more  viable  for  the  proposed 
system  than  others.  For  example,  the  LAV  platform  that  is  used  in  this  report  as 
an  exemplar  may  be  a  suitable  platform  for  implementation  because  of  an 
already  strong  history  including  service-life  extension  plan  (SLEP)  and 
considerable  presence. 

Second,  the  scenarios  painted  should  be  considered  as  the  basis  for  determining 
the  infrastructure,  which  may  evolve  from  simple  to  more  complex.  Some 
decisions  about  the  infrastructure  are,  however,  stable  and  endure  over  time. 
These  should  be  identified  early  following  an  analysis  of  the  use  cases.  Based  on 
these,  the  infrastructure  can  be  designed  so  that  it  evolves  is  the  desired 
direction.  If  the  infrastructure  decisions  indicate  that  the  most  preferred 
alternative  is  not  available,  it  may  be  necessary  to  revise  the  use  cases.  For 
example,  a  prerequisite  for  some  of  the  use  cases  is  wireless  technology.  If  the 
most  preferred  wireless  alternative  is  not  available  for  any  reason,  it  may  be 
necessary  to  revise  the  use  cases  devised. 

Third,  changes  to  the  work  practices  should  be  identified  and  proactively  planned 
for  during  a  successful  transition  plan.  The  proposed  IDGE  system  will  push 
more  intelligence  to  lower  levels  of  the  organizational  hierarchy.  In  many  ways, 
this  is  in  direct  contrast  to  the  command  and  control  mechanisms  put  in  place. 
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This  will  require  changes  to  work  procedures  and  reward  mechanisms. 
Contemporary  research  on  workflow  management  and  collaborative  systems  can 
be  leveraged  towards  this  purpose. 


6.6  Future  Directions 

Comments  provided  on  the  draft  final  report  indicate  possible  future  steps  for  this 
study  that  correspond  to  some  of  our  suggestions  for  future  plans.  In  particular,  it 
may  be  possible  to  develop  prototypes  for  different  aspects  of  the  proposed 
system.  These  can  include  prototyping  novel  user  interfaces  for  computer-human 
interactions  to  investigate  concerns  such  as  will  PDAs  work  in  this  context.  This 
can  also  include  creating  simulations  at  the  workflow  /  scenario  levels  of  the 
IDGE  system  as  well  as  the  potential  users  and  structures  to  ensure  that  key 
issues  such  as  motivators  etc  are  taken  into  account. 

The  system  requirements  that  have  been  developed  for  the  IDGE  system  have  to 
be  used  to  first  develop  a  prototype  system.  The  prototype  system  will  have  all 
the  functionalities  but  can  be  scaled  up  after  sufficient  validation.  Building  a 
prototype  system  help  in  the  following  aspects 

Will  help  refine  the  requirements  specification  to  greater  detail 
-  Conformance  to  the  operational  architecture  of  the  working  system 
can  be  ascertained 

The  performance  of  the  system  can  be  analyzed  and  specific 
modules  can  be  redesigned  to  improve  performance 
The  prototype  can  be  used  to  train  the  users  while  transitioning  to 
large  scale  deployment 
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8  Appendices 

8. 1  Maintenance 

8.1.1  Maintenance  Practices  in  USMC 

a)  Equipment  Repair  Order  (ERO): 

•  It  is  a  paper  based  form  within  a  unit,  which  is  used  for  request 
modification,  calibration,  corrective  maintenance,  preventive  maintenance 
checks  and  services  and  technical  inspections  on  all  ground  equipment 

•  Can  also  be  used  to  transfer  work  to  higher  echelons  of  maintenance  and 
for  recording  and  reporting  the  maintenance  that  has  been  performed. 

b)  Equipment  Repair  Order  Shopping/Transaction  List  (EROSL): 

•  The  EROSL  will  be  used  in  conjunction  with  the  ERO  to  requisition,  receipt 
for,  cancel,  and  record  partial  issues  and  credits  of  repair  parts  associated 
with  ground  equipment  undergoing  repairs. 

•  The  ERO  holder  is  responsible  for  initial  preparation  of  the  EROSL  to 
include  the  required  information. 

•  To  input  MIMMS  data  into  the  system,  either  automated  or  manual. 

c)  Equipment  Records:  There  are  many  records  but  the  two  most  predominant 
ones  are:  preventive  maintenance  checks  and  services  (PMCS)  records  and 
corrective  maintenance  (CM)  records. 

•  PMCS  record  ensures  that  the  PM  is  systematically  scheduled  and 
recorded  when  complete 

•  CM  record  ensures  that  a  history  is  established  for  the  piece  of  ground 
equipment  that  requires  to  be  maintained. 

d)  Calibration  control  Program: 

•  It  ensures  that  all  Test,  Measurement  and  Diagnostic  Equipment  (TMDE) 
is  calibrated  within  certain  range  of  scale. 

e)  Tool  Control: 

•  Ensures  accountability  of  all  tools  in  stand-alone  sets,  chests  or  kits  and  or 
if  they  belong  to  a  PEI. 

f)  Product  Quality  Deficiency  Report  (PQDR): 

•  Provides  information  to  activities  responsible  for  development, 
procurement,  or  management  of  equipment  concerning  deficiencies  in 
material,  design,  or  procurement 

•  It  enables  the  activities  to  initiate  action  to  correct  the  reported  deficiency. 

g)  Modification  Control:  This  program  gives  the  equipment  owner  the  means  of 
accurately  determining  the  modification  status  on  assigned  equipment.  There 
are  two  types  of  modification:  Urgent  and  Normal. 
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•  Normal:  modification  lend  themselves  to  acceptance  scheduling  usually 
within  one  year 

•  Urgent:  modification  requires  that  the  equipment  be  dead  lined  or  sharply 
curtailed  until  the  modification  is  applied. 

h)  Publication  Libraries:  The  publications  fall  into  two  categories: 

•  Technical  (Marine  Corps  Orders,  Bulletins,  etc.) 

•  Non-technical  (Technical  Manuals,  Stock  Listings,  Modification 
Instructions,  etc.). 


8.1.2  Maintenance  Systems 

Marine  Corps  Integrated  Maintenance  Management  Systems  (MIMMS)  and 

Field  Maintenance  Systems 

The  Marine  Corps  Integrated  Maintenance  Management  System  is  an 
automated  management  system.  It  is  organized  into  three  subsystems:  the 
Headquarters  Maintenance  Subsystem,  the  Depot  Maintenance  Subsystem,  and 
the  Field  Maintenance  Subsystem. 

The  Headquarters  Maintenance  Subsystem  supports  commodity  managers  at 
Headquarters  Marine  Corps.  It  allows  commodity  managers  (i.e.,  motor 
transport,  communications-electronics,  engineer,  and  ordnance)  to  enter 
standard  data  into  the  Marine  Corps  Integrated  Maintenance  Management 
System  and  to  maintain  a  database  of  selected  maintenance  information.  This 
data  base  is  comprised  of  information  extracted  from  the  Field  Maintenance 
Subsystem.  It  facilitates  selective  maintenance  engineering  analysis,  logistic 
readiness  evaluation,  and  maintenance  management  for  specified  functions 
required  by  the  Headquarters  Maintenance  Subsystem  user. 

The  Depot  Maintenance  Subsystem  supports  the  materiel  functions  of  the  two 
Marine  Corps  depot  maintenance  activities.  It  provides  materiel  and  production 
control  information  and  cost  and  labor  accounting  information 


The  Field  Maintenance  Subsystem  was  developed  to  improve  and  standardize 
equipment  status  reporting  and  management,  while  reducing  and  consolidating 
manual  reporting  requirements.  It  provides  commanders  with  timely  and 
accurate  information  concerning  the  status  of  equipment  currently  in  the 
maintenance  cycle.  This  system  provides  maintenance  and  repair  parts 
information,  supply  transactions,  historical  costs,  and  tracking  of  maintenance 
engineering  and  modification  control  information.  The  primary  inputs  to  this 
system  are  the  ERO  and  the  EROSL. 

From  the  above  review,  we  have  identified  the  need  for  an  integrated  system  that 
can  handle  transactions  in  addition  to  storing  and  cataloguing  information.  This 
will  provide  greater  visibility  for  all  three  levels  of  maintenance. 
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Marine  Corps  Equipment  Readiness  Information  Tool  (MERIT) 

MERIT  is  a  non-transactional  web  based  tool  currently  in  use  at  the  USMC.  Its 
key  functions  include  enabling  visualization  of  the  equipment  readiness  status  by 
using  detailed  supply  and  maintenance  information.  MERIT  transforms  the 
maintenance  data  into  relevant  information  that  provides  a  near  real  time  view  of 
equipment  readiness.  It  presents  a  comprehensive  Marine  Corps  readiness 
posture  while  presenting  detailed  information  about  the  availability  of  specific 
parts.  It  contains  a  graphical  user  interface  in  combination  with  a  readiness 
analysis  tool.  It  essentially  automates  the  process  of  developing  detailed 
readiness  maps.  Thus  it  reduces  the  workload  on  the  analysis  experts. 

MERIT  uses  an  open  source  java-based  programming  technique.  The  delivery 
method  uses  a  web  browser  using  java  applet  running  on  a  server,  this  is 
connected  to  the  data  source  such  as  Oracle,  XML  or  delimited  text.  MERIT  also 
uses  a  combination  of  filters;  labels  and  search  tools  to  either  group  the  data  in 
numerous  desired  ways  or  for  presenting  multiple  calculations  for  current  and 
historical  USMC  readiness  data.  It  also  uses  different  color  schemes  for 
representing  the  data  element  and  thus  enables  easy  visualization. 

A  critical  review  of  the  MERIT  system  helped  the  team  identify  the  different 
maintenance  data  that  the  system  is  currently  capturing.  It  also  helped  the  team 
review  the  techniques  that  are  used  to  store/catalogue  the  data  elements. 
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8.3  Database  Tables 

Table  8.3:  Supply  Information  Table 


or  Main  Database  Description 


Database  Name 

IDGE_MAIN 

Date 

Table  Name 

Supply Jnfo 

Writer 

Table  Description 

This  gives  supply  information  to  order  new  parts 

No 

Field  Name 

PK 

Type 

Size 

Description 

1 

SUPPLIERJD 

PK 

Supplier  Id 

2 

SJREQJD 

PK 

Supply  Request  Id  (create  new  supply  id) 

3 

EROSLJD 

PK 

EROSL  identification  number 

4 

PARTJD 

PK 

Required  Part  Id  (Serial  No.  of  the  part) 

5 

Quan_Part 

Required  Part  Id  (in  Quantities) 

6 

REQUEST_DATE 

Part  requirement  date 

7 

PRIORITY 

Priority  number  for  supply  request 

8 

S_RETJD 

Supply  Retailers  like  DoD  etc.  Identification 

9 

MODE_TRANS 

Mode  of  Transportation  for  shipment 

10 

ESD_DATE 

Estimated  Shipping  Date 

11 

EDDJDATE 

Estimated  Delivery  Date 

12 

ECD_DATE 

Estimated  Complete  Date 

13 

RRD_DATE 

Required  Ready  Date 

Particulars 
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Table  8.4:  RM  Information  Table  for  Main  Database  Description 


Database  Name 

IDGE_MAIN 

Date 

Table  Name 

RMJnfo 

Writer 

Table  Description 

This  table  is  related  to  the  information  for  each  request  manager  (RM). 

No 

Field  Name 

PK 

Type 

Size 

Description 

1 

RMJD 

PK 

Request  manager's  ID.  (it  also  can  be  used  as  a 
system  access  ID.) 

2 

RM_PASS 

Password  for  the  system  access 

3 

NAME 

Name 

4 

RMJ3RADE 

Grade  (i.e.  Sergeant,  lieutenant,  etc.) 

5 

CSSEJD 

His/her  home  unit  (i.e.  CSSE  Det.  1) 

6 

PHONE 

Phone  number 

7 

REMARKS 

Descriptions 

Particulars 

Instead  of  RMJD,  SSN  also  can  be  used  as  an  alternative,  (since,  it  follows  uniqueness  property.) 
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Table  8.5:  Repair  Request  Table  for  Main  Database  Description 


Database  Name 

IDGE_MAIN 

Date 

Table  Name 

REPAIR  JREQUEST 

Writer 

Table  Description 

This  is  related  to  the  information  for  each  repair  request. 

No 

Field  Name 

PK 

Type 

Size 

Description 

1 

REQJD 

PK 

Repair  request  ID 

2 

REQNO. 

Repair  order  number  from  supported  unit. 

3 

REQ_STATUS 

Request  state  (i.e.  pending  or  assigned) 

4 

SUPERVISORJD 

Supervisor  ID 

5 

RM_ID 

Request  manager  ID 

6 

CSSEJD 

CSSE  det.  ID.  (if  there  is  only  one  RM  for  each  CSSE 
Det,  this  attribute  may  be  redundant.) 

7 

S_UNIT_ID 

Supported  unit  ID.  (if  there  is  only  one  supervisor  for 
each  supported  unit,  this  attribute  may  be  redundant.) 

8 

PLTJD 

Platoon  Id 

9 

MT_TYPE 

Maintenance  Type  (Periodic: 0 ,  Aperiodic:1) 

10 

DEFECT_CODE 

Defect  Code  (or  Failure  Code) 

11 

BRDN_DATE 

Break  Down  Date 

12 

LOC_CODE 

Location  Code  (probably  redundant,  if  PLTJD  is 
included  in  this  table.) 

13 

ALM_STATUS 

Alarm  Status 

14 

REQ_DATE 

Requested  date  from  a  supervisor 

15 

OPERATORJD 

LAV  operator  ID 

16 

LAV_ID 

LAV  ID 

17 

MILEAGE 

MILEAGE  for  LAV 

18 

OPERATING  DAY 

S 

NUMER  OF  OPERATING  DAYS 

Particulars 

It  should  be  considered  that  there  might  be  several  redundant  attributes. 

Should  we  consider  all  CSSE  Dets  share  only  one  table  for  the  repair  request?  Or  each  CSSE  Det.  has  its  own 
repair  request  table. 
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Table  8.6:  Mechanic  Information  Table  for  Main  Database  Description 


Database  Name 

IDGE_MAIN 

Date 

Table  Name 

Mechanic_lnfo 

Writer 

Table  Description 

This  is  related  to  the  information  for  each  mechanic  in  CSSE  Det. 

No 

Field  Name 

PK 

Type 

Size 

Description 

1 

MECHJD 

PK 

Request  manager’s  ID.  (it  also  can  be  used  as  a 
system  access  ID.) 

2 

ME_GRADE 

Grade  (i.e.  Sergeant,  etc.) 

3 

SPEC_CODE 

His/her  maintenance  specialty. 

4 

SKILL_LEVEL 

His/her  maintenance  skill  level. 

5 

NUM_TASK 

Number  of  assigned  tasks  (repair  requests) 

6 

EXPJDATE 

Expected  available  date. 

7 

PHONE 

Contact  phone  number  (or  e-mail) 

8 

AVALIABILITY 

Quantity  of  tool  available 

9 

EXPECTED  AVAL 
IABILITY 

Number  of  queue  for  reserve  this  tool 

Particulars 

Instead  of  RMJD,  SSN  also  can  be  used  as  an  alternative.  (Since,  it  follows  uniqueness  property.) 
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Table  8.7:  Part  Information  Table  for  Main  Database  Description 


Database  Name 

IDGE_MAIN 

Date 

Table  Name 

Partjnfo 

Writer 

Table  Description 

This  is  related  to  the  information  for  each  part. 

No 

Field  Name 

PK 

Type 

Size 

Description 

1 

NSN 

PK 

National  stock  number 

2 

niin 

National  item  identification  number 

3 

NOMENCLATURE 

Part  name 

4 

QUAD_CLASS 

Quadrant  (priority)  class  (if  necessary) 

5 

QUAN_CSSE_01 

Quantity  of  this  part  the  CSSE  Det  1  has 

6 

QUANCSSE02 

Quantity  of  this  part  the  CSSE  Det  2  has. 

7 

QUAN_CSSE_03 

Quantity  of  this  part  the  CSSE  Det  3  has. 

8 

QUANTITY 

Total  quantities  of  this  part 

9 

COST 

Cost 

10 

R_COST 

Repair  cost  for  this  part 

11 

S_ld 

Supplier  code 

12 

PART_GROUP 

Part  group  (i.e.  group  tech.) 

13 

MAKER 

14 

END  ITEMS 

15 

SUBSYSTEM,  CODE 

16 

TRANSPORTATION 

REQUIREMENTS 

17 

LOCATION  ID 

Warehouse  id,  Shelves  id,  etc 

Particulars 
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Table  8.8:  Tool  Information  Table  for  Main  Database  Description 


Database  Name 

IDGE_MAIN 

Date 

Table  Name 

Tool_lnfo 

Writer 

Table  Description 

This  is  related  to  the  information  for  each  maintenance  tool  or  facility. 

No 

Field  Name 

PK 

Type 

Size 

Description 

1 

TOOLJD 

PK 

Tool  or  facility  ID 

2 

TOOL_NAME 

Tool  or  facility  name 

3 

OWNINGJJNITJD 

4 

AVAILABITITY 

Quantity  of  tool  available 

5 

EXPECTED  AVAILABI 
LITY 

Number  of  queue  for  reserve  this  tool 

6 

REMARKS 

Descriptions 

Particulars 
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Table  8.9:  User  Information  Table  for  Main  Database  Description 


Database  Name 

IDGE_MAIN 

Date 

Table  Name 

Userjnfo 

Writer 

Table  Description 

This  is  related  to  task  information  for  each  mechanic. 

No 

Field  Name 

PK 

Type 

Size 

Description 

1 

UserJD 

User  Id 

2 

Passwd 

Password 

3 

SSN 

Social  Security  Number 

4 

RANK 

Colonel,  Major,  Captain,  etc 

5 

Position 

Supervisor,  RM,  OM,  etc 

6 

Supervisorjd 

Supervisorjd 

7 

RM_ld 

RM  Id 

8 

CSSEJd 

CSSE  Id 

9 

FSSGJd 

FSSG  Id 

Particulars 
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Table  8.10:  LAV  Information  Table  for  Main  Database  Description 


Database  Name 

IDGE_MAIN 

Date 

Table  Name 

LAVJNFO 

Writer 

Table  Description 

This  is  the  table  for  LAV  Basic  Information. 

No 

Field  Name 

PK 

Type 

Size 

Description 

1 

LAVJD 

* 

LAV  Id 

2 

N_Mileage 

LAV  Mileage 

3 

POSITIONJ_AV 

Position  or  Location  of  LAV  (GPS) 

4 

STATUS 

LAV  statues  -  Normal  or  Failure 

5 

OPERATOR 

Operator 

Particulars 
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Table  8.11:  History  of  Maintenance  Table  for  Main  Database  Description 


Database  Name 

IDGE_MAIN 

Date 

Table  Name 

HISTORY,  MAINT 

Writer 

Table  Description 

This  is  the  table  for  Maintenance  History  of  LAV. 

No 

Field  Name 

PK 

Type 

Size 

Description 

1 

LAVJD 

* 

LAV  Id 

2 

Reqjd 

Request  Id 

3 

NJMileage 

LAV  Mileage 

4 

PROBLEM 

Title  of  Problem 

5 

DEFECT_CODE 

Defect  Code 

6 

DATEJMAINT 

Date  of  Maintenance 

7 

REPAIRED_PART 

Parts  related  Maintenance 

8 

MECHANIC 

Mechanics  related  maintenance 

9 

REFERENCE 

Mechanic's  Comments 

Particulars 

Table  8.12:  Related  Part  Table  for  Main  Database  Description 


Database  Name 

IDGEJMAIN 

Date 

Table  Name 

Related_Part 

Writer 

Table  Description 

This  table  shows  the  relationship  between  defect  code  and  part  code. 

No 

Field  Name 

PK 

Type 

Size 

Description 

1 

DEFECT_CODE 

PK 

Defect  Code 

2 

Part_Code 

Part  List  and  NSN  of  related  with  Defect  Code 

Particulars 
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Table  8.13:  Related  Tool  Table  for  Main  Database  Description 


Database  Name 

IDGE_MAIN 

Date 

Table  Name 

Related_Tool 

Writer 

Table  Description 

This  table  shows  the  relationship  between  defect  code  and  tool  code. 

No 

Field  Name 

PK 

Type 

Size 

Description 

1 

DEFECT_CODE 

* 

Defect  Code 

2 

Tool_Code 

Part  List  and  NSN  of  related  with  Defect  Code. 

Particulars 

Table  8.14:  Defect  Code  Information  Table  for  Main  Database  Description 


Database  Name 

1  IDGE_MAIN 

Date 

Table  Name 

Defect_Code_lnfo 

Writer 

Table  Description 

This  is  the  table  consisting  defect  code. 

No 

Field  Name 

PK 

Type 

Size 

Description 

1 

DEFECTJ30DE 

★ 

Defect  Code 

2 

Description 

Part  List  and  NSN  of  related  with  Defect  Code. 

3 

Alm_Status 

Particulars 
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Table  8.15:  Repair  Request  Table  for  CLIENT  Database  Description 


Database  Name 

IDGE_CLIENT 

Date 

Table  Name 

Repair_Request 

Writer 

Table  Description 

This  table  is  related  to  the  information  for  each  repair  request. 

No 

Field  Name 

PK 

Type 

Size 

Description 

1 

REQJD 

PK 

Repair  request  ID 

2 

REQ_NO. 

Repair  order  number  from  supported  unit. 

3 

REQ_STATUS 

Request  state  (i.e  pending  or  assigned) 

4 

SUPERVISORJD 

Supervisor  ID 

5 

RM_ID 

Request  manager  ID 

6 

CSSEJD 

CSSE  Det.  ID.  (if  there  is  only  one  RM  for  each  CSSE 
Det,  this  attribute  may  be  redundant.) 

7 

S_Unit_ld 

Supported  unit  ID.  (if  there  is  only  one  supervisor  for 
each  supported  unit,  this  attribute  may  be  redundant.) 

8 

PLTJD 

Platoon  Id 

9 

MT_TYPE 

Maintenance  Type  (Periodic:0,  Aperiodic;1) 

10 

DEFECT_CODE 

Defect  Code  (or  Failure  Code) 

11 

BRDN_DATE 

Break  Down  Date 

12 

LOC_CODE 

Location  Code  (probably  redundant,  if  PLTJD  is 
included  in  this  table.) 

13 

ALM_STATUS 

Alarm  Status 

14 

REQ_DATE 

Requested  date  from  a  supervisor 

15 

OPERATORJD 

LAV  operator  ID 

16 

LAVJD 

LAV  ID 

Particulars 

It  should  be  considered  that  there  may  be  several  redundant  attributes. 

Should  we  consider  all  CSSE  Dets  share  only  one  table  for  the  repair  request9  Or  each  CSSE  Det.  has  its  own 
repair  request  table. 
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Table  8.16:  Mechanic  Schedule  Table  for  CLIENT  Database  Description 


Database  Name 

IDGE_CLIENT 

Date 

Table  Name 

Mechanic_Schedule 

Writer 

Table  Description 

This  table  is  related  to  the  work  order  schedule  for  each  mechanic 

No 

Field  Name 

PK 

Type 

Size 

Description 

1 

Mechanicjd 

PK 

Mechanic  ID 

2 

Taskjd. 

3 

Locjd 

Location  Code  (probably  redundant,  if  PLT_ID  is 
included  in  this  table,) 

4 

LAVJd 

LAV  ID 

5 

Defect_Code 

Defect  Code  (or  Failure  Code) 

6 

CSSEJD 

CSSE  Det  ID,  (if  there  is  only  one  RM  for  each  CSSE 
Detr  this  attribute  may  be  redundant.) 

7 

FSSGJD 

FSSG  ID 

8 

MISTYPE 

Maintenance  Type  (Periodic  O,  Aperiodic:1) 

9 

ALM_STATUS 

Alarm  Status 

10 

REQ_DATE 

Requested  date  from  a  supervisor 

Particulars 
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8.4  Use  Cases 

8.4.1  Use  Case  Documentation  and  User  Interfaces 


Use  Case  1:  Record  Sensor  Data  in  Black  Box 


Preconditions: 

•  Sensors  in  place  at  the  LAV  to  collect  data  streams. 

Actors: 

•  Sensors 

Goal: 

To  gather  sensor  data  from  sensors  in  each  vehicle  and  store  it  in  the  black  box  on  board  of  the 
vehicle. 

Flow  of  events: 

1  Each  sensor  in  the  vehicle  gathers  and  transmits  data  via  hardwired  link  into  the  black  box 
that  is  onboard  the  vehicle. 

2.  The  data  is  stored  using  a  predetermined  structure  in  the  black  box. 

3  If  the  capacity  of  the  black  box  is  exceeded  before  upload  (see  use  case  2:  periodically 

upload  sensor  data  from  black  box  in  each  LAV)  the  oldest  data  is  overwritten  to  maintain  the 
most  recent  data  stream  from  each  sensor  in  the  black  box. 

Related  Use-Cases: 

Periodically  upload  sensor  data  from  black  box  in  each  LAV 

Frequency  and  Levels 

Frequency  of  usage: 

Once  a  day  for  each  LAV 

Level  of  operation:  Vehicle  G^  M4 

G3- - MS 


Data  transmitted 


None  across  the  levels 


Algorithms  and  Decision  Support  Tools 

Algorithms  used: 

Data  compression  and  storage  algorithm  as  needed 

Decision  support  tools: 

None 


User  Interface:  None 
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Use  Case  2:  Query  a  Sensor 


Precondition: 

•  Employment  of  some  wireless  technology  and  multiplexing  technique  for  communication 
between  vehicle  system  processor  and  the  maintenance  analysts  (O-level). 

.  Transmitter  system  is  in  place  at  the  mechanic  location  (O-level)  to  send  query  signal  to  the 
vehicle  system  processor. 

•  Query  to  be  sent  only  if  normal  periodic  upload  of  data  from  vehicle  system  processor  to  0- 
level  does  not  take  place  for  a  particular  subsystem 

Actors: 

•  Maintenance  analyst  at  O-level 

•  Sensor 

Goal: 

To  ping/  trigger  the  vehicle  system  processor  to  upload  the  sensor  data  stream  of  the  “missing” 
vehicle  subsystem  to  O-level. 

Flow  of  events: 

1  O-level  system  processor  checks  O-level  database  to  determine  the  time  stamp  on  the  last 
reception  from  a  particular  subsystem  sensor  emanating  from  the  vehicle  level. 

2.  (If  pre-determined  time  limit  elapsed)  O-level  system  processor  retrieves  vehicle,  subsystem 
id  and  criticality  index  from  database. 

3  System  alerts  O-level  maintenance  analyst 

4.  O-level  system  processor  initiates  query  to  vehicle  system  processor  about  "missing” 
subsystem  sensor  and  stamps  priority  code  on  query  (depending  on  criticality  index) 

5.  O-level  system  processor  queues  such  outgoing  queries  depending  on  the  priority  code 

6.  O-level  system  processor  records  the  query  time  in  database 
7  O-level  system  processor  transmits  query  signal 

Alternative  Flows: 

1 ,  (If  time  limit  not  elapsed)  System  rests 

Related  Use-Cases:  Periodically  upload  sensor  data  from  black  box  in  each  vehicle 

Frequency  and  Levels 

Frequency  of  usage:  10%  of  use  case:  "upload  sensor  data  from  black  box  in  each  vehicle" 

Level  of  operation:  Vehicle  Cl  M4 

GG— - — MG 

G3 - M3 


Data  Implications 

Vehicle  Cl  20k 
Cl  vehicle:  Ik 

Algorithms  and  Decision  Support  Tools 

Algorithms  used:  O-level  database  monitoring  to  determine  any  “missing”  subsystem  sensors 
(sensor  signal  reception  overdue) 
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Use  Case  3:  Periodically  Upload  Sensor  Data  from  Black  Box  in  Each 
Vehicle 


Preconditions: 

•  Existing  wireless  technology  for  communication  between  the  field  and  the  O-level. 

•  Black  box  in  place  at  the  vehicle  to  collect  the  data  from  multiple  sensors  in  the  vehicle. 

•  Transmitter  system  in  place  at  the  vehicle  to  transmit  sensor  signals  from  the  black  box. 

•  Receiver  system  is  in  place  at  the  O-level  to  receive  the  signals  and  pre-process. 

Actors: 

•  Vehicle  mechanic 

•  Maintenance  analyst  at  O-level 

Goal: 

To  upload  sensor  data  from  each  vehicle  at  predetermined  intervals. 

Flow  of  events: 

4.  Transmitter  at  the  vehicle  uploads,  at  a  predetermined  time,  sensor  data  collected  over  the 
last  period,  currently  specified  at  24  hours.  (Note:  This  is  the  preferred  course  of  action,  when 
the  vehicle  is  engaged  in  a  battle  situation  and  has  traveled  far  from  the  base.) 

5.  Receiver  at  the  O-level  authenticates  the  source  of  the  data  stream  from  the  field  to  ensure 
that  it  originates  from  validated  vehicle/personnel. 

6.  The  system  processor  at  O-level  automatically  verifies/decodes  the  signal  from  the  vehicle 
(the  signal  contains  the  authenticated  code). 

7.  If  successful,  the  O-level  maintenance  analyst  releases  the  data  stream  for  storage  and 
update  of  the  database.  (Note:  This  step  is  a  manual  check  to  ensure  that  correct  data  is 
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uploaded  to  the  database.  Though  this  has  a  cost  i.e.  time,  it  ensures  the  integrity  of  the 
database.) 

Alternative  Flow  1: 

1 .  If  the  vehicle  operator  notices  something  wrong  with  the  vehicle  but  does  not  know  the  cause, 
he/she  may  initiate  an  upload  from  the  black  box  even  if  it  the  upload  is  not  due. 

2  The  remaining  steps  for  a  wireless  upload  remain  the  same. 

Alternative  Flow  2: 

1.  If  an  upload  could  not  be  attempted  (e.g.  because  of  being  in  the  battle  or  out  of  range  from 
wireless  communications)  or  was  not  successful  for  any  reason,  the  black  box  in  the  vehicle 
stores  the  last  24  hours  of  the  sensor  data. 

2  At  the  next  predetermined  time,  the  upload  is  again  attempted. 

3.  The  remaining  steps  for  a  wireless  upload  remain  the  same. 

Alternative  Flow  3: 

1.  Every  day,  a  vehicle  mechanic  visits  front  where  the  vehicles  are  deployed  with  a  notebook. 
(Note:  This  is  the  preferred  course  of  action,  when  the  vehicle  has  not  traveled  far  from  the 
base  and  is  not  in  active  battle.  The  desire  to  present  a  friendly  face  to  the  vehicle  crew  on  a 
daily  basis  drives  this  step.) 

2.  The  vehicle  mechanic  downloads  the  contents  of  the  black  box  from  each  vehicle  into  the 
notebook  using  a  hardwired  connection. 

3.  The  vehicle  mechanic  returns  to  the  base,  and  connects  the  Notebook  to  the  database  to 
upload  the  data  to  the  history  database.  (Note.  No  further  check  from  the  mechanic  is  needed 
-  like  the  last  step  in  the  main  flow  -  using  this  alternative  because  the  data  is  gathered  from 
the  vehicles  using  a  hardwired  connection  i.e.  the  integrity  of  the  database  is  not  likely  to  be 
compromised.) 

Related  Use-Cases: 

Report  out  of  ordinary  event 


Frequency  and  Levels 


Frequency  of  usage: 

Once  a  day  for  each  vehicle 

Level  of  operation:  Vehicle  Cl 

GQr 

—MS 

£3- 

-M3 

Data  Implications 

Vehicle  Cl:  20Mb  (data  stream  from  sensors,  e  g.  date,  time,  number  of  vehicle,  etc.) 

Cl  vehicle:  0.5k  (user  ID,  number,  etc.) 

Algorithms  and  Decision  Support  Tools 

Algorithms  used: 

Authentication  procedure  to  validate  data  source 
Wireless  reception  and  decoding  techniques 

Decision  support  tools: 

Alert  to  mechanic  at  Battalion  level  of  incoming  data  stream 
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Use  Case  4;  Report  a  Breakdown 


Precondition: 

•  The  operator  in  the  vehicle  has  detected  the  malfunctioning  sub  system  and  determined  that 
he  needs  assistance  from  the  Battalion  level  mechanic. 

•  Existing  wireless  technology  for  communication  between  the  field  and  the  Battalion  level. 

•  Transmitter  system  in  place  at  the  vehicle  to  transmit  the  breakdown  report. 

•  Receiver  system  is  in  place  at  the  Battalion  to  receive  the  signals  and  pre-process. 

Actors: 

•  Vehicle  operator 

Goal: 

To  seek  assistance  from  Battalion  level  in  troubleshooting/  diagnosis  of  the  faulty  sub  system  if 

the  vehicle  operator  is  unable  to  troubleshoot  it  himself 

Flow  of  events: 

1 .  The  vehicle  operator  describes  the  breakdown  such  as  the  subsystem  abnormality  observed, 
time  observed  and  other  details  as  comments.  A  proposed  implementation  of  this  is  with  a 
form  on  a  Personal  Digital  Assistant  (PDA)  such  as  a  Palmtop  PC. 

2  The  system  prompts  for  information  such  as  vehicle  id,  date,  time,  mileage. 

3.  The  system  presents  a  menu  of  choices  for  subsystems  (e  g.  Alternator,  Brake  Systems, 
Carburetion)  that  map  to  MIMMS  codes  (available  on  pages  24-3  to  24-5  of  the  MIMMS  AIS 
Field  Maintenance  Procedures  User  Manual) 

4.  The  operator  selects  from  this  menu,  and  enters  further  description  of  the  problem,  if 
necessary. 

5.  The  operator  ‘sends’  the  form  using  available  wireless  technology  to  the  team  of  mechanics 
at  the  Battalion  level. 

Related  Use-Cases: 

Process  PDA  form  at  the  Battalion  level 
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Frequency  and  Levels 


Frequency  of  usage: 

One  breakdown  per  vehicle  per  week 

Level  of  operation:  Vehicle  Cl 

m 

GO- 

GG 

- M3 

Data  Implications 

Vehicle  -4  Cl:  20k  (vehicle  ID,  date, 
Cl  4  vehicle:  none 

time,  problem  description,  etc.) 

Alqorithms  and  Decision  Support  Tools 

Algorithms  used: 

System  assistance  (user  prompts)  in  filling  PDA  form 

Decision  support  tools: 

None  (Personal  decision  by  vehicle  mechanic) 
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Use  Case  5:  Process  a  Breakdown  Report  at  O-Level 


Precondition: 

•  Breakdown  reports  are  received  from  a  vehicle  in  the  field  and  authenticated,  decoded  and 
available  for  processing. 

•  Existing  wireless  technology  for  communication  between  the  field  and  the  O  level. 

•  Transmitter  system  in  place  at  the  vehicle  to  transmit  the  breakdown  from  the  vehicle. 

•  Receiver  system  is  in  place  at  the  O  level  to  receive  the  signals  and  pre-process 

Actors: 

•  Maintenance  analyst  at  O  level 

Goal: 

To  attempt  to  analyze  the  information  received  from  the  PDA  that  gives  further  description  about 
the  failure  (or  impending  failure)  of  the  subsystem,  with  a  view  to  diagnose  the  problem 
successfully. 

Flow  of  events: 

1.  The  system  stores  the  received  breakdown  reports  into  the  database. 

2.  The  system  alerts  the  mechanic  about  receipt  of  breakdown  reports  from  vehicles. 

3.  The  system  displays  a  list  of  breakdowns  reported  to  the  mechanic. 

4.  The  mechanic  can  select  a  breakdown  reported  to  see  further  information  about  it  such  as 

the  problem  description  received  from  the  vehicle. 

5.  The  mechanic  schedules  a  mechanic  visit  to  the  affected  vehicle  to  perform  diagnosis  (see 
“diagnosis  of  subsystem  at  O-level”) 

6.  The  system  stores  the  schedule  and  alerts  the  mechanic,  whose  responsibility  it  is  to  visit  the 
vehicle  -  either  in  the  field  or  when  the  vehicle  returns  to  base. 

7.  The  system  stores  the  status  of  the  breakdowns  reported  as  ‘visit  scheduled  from  the 
mechanic.’ 

Alternative  Flows: 

None 

Related  Use-Cases: 

Report  out  of  ordinary  event 
Authenticate  received  field  signals 
Diagnosis  of  subsystem  at  O-level 

Frequency  and  Levels 

Frequency  of  usage: 

One  breakdown  per  vehicle  per  week 

Level  of  operation:  Vehicle  Cl  M 4 

C2  M2 

ca  m 


Data  Implications 


Vehicle  Cl  none 
Cl  vehicle:  none 
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Algorithms  and  Decision  Support  Tools 

Algorithms  used:  O-level  database  search  and  retrieval  of  LAV  subsystem  data 
System  analysis  algorithm  of  PDA  form,  Database  update  on  information  received 

Decision  support  tools:  Display  of  analysis  results  (Front  end),  Alert  to  O-level  mechanic  of 
analysis  results/  potential  corrective  solutions 


Use  Case  6:  Perform  Diagnosis  of  a  Subsystem  at  O-Level 


Precondition: 

•  Sensor  data  stream  of  an  vehicle  (for  the  past  24  hours)  has  been  uploaded  to  the  O-level 
(see  use  case  “Periodically  upload  sensor  data  from  black  box  in  each  vehicle”)  or 

•  A  breakdown  reported  from  the  vehicle  operator  has  been  processed  at  the  Battalion  level 
(see  use  case  “Process  reported  breakdowns  at  the  O-level”) 

Actors: 

•  Maintenance  person  at  the  O-level 

Goal: 

•  To  diagnose  the  health  of  a  subsystem  of  an  vehicle  based  on  information  received  from  the 
vehicle  (either  uploaded  data  stream  or  reported  breakdown  from  the  vehicle  operator)  to 
determine  component  failure. 
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Flow  of  events: 

1  The  maintenance  person  at  the  O-level  retrieves  vehicle  and  subsystem  information  from  the 
database  (see  precondition  above,  which  indicates  the  use  case,  which  has  previously 
populated  the  database). 

2  The  maintenance  person  performs  a  physical  inspection  of  the  vehicle,  called  a  Limited 
Technical  Inspection  (LTI),  which  is  stored  into  the  database. 

3.  The  maintenance  person  studies  the  information  retrieved  and  the  LTI  to  determine  the 
nature  of  problem  (diagnosis)  and  resolution  measures. 

4  If  the  diagnosis  is  successful,  the  maintenance  person  triggers  the  use  case  “Initiate  Repairs 
by  filling  out  an  Eguipment  Repair  Order  (ERO).” 

5  If  he  is  unable  to  diagnose,  he  triggers  the  use  case  "Escalate  diagnosis  from  O-level  to  I- 
level"  and  this  use  case  stops 

6.  System  records  the  action  in  database,  and  tags  the  vehicle  as  'waiting  for  maintenance.' 

Alternative  Flows: 

None 

Related  Use-Cases: 

•  Periodically  upload  sensor  data  from  black  box  in  each  vehicle 

•  Process  a  breakdowns  report  at  the  O-level 

•  Initiate  Repairs  by  filling  out  an  Eguipment  Repair  Order  (ERO) 

•  Escalate  diagnosis  from  O-level  to  l-level 

Frequency  and  Levels 

Frequency  of  usage: 

One  breakdown  per  vehicle  per  week 

Level  of  operation:  Vehicle  Cl  Ml 

G2  M2 

GO-  440 


Data  Implications 

Cl  Ml:  20k  (processed  information  for  the  vehicle) 

Ml  Cl:  20k  (ERO  description) 

Algorithms  and  Decision  Support  Tools 

Algorithms  used:  Database  updates  on  entering  of  action  taken 

Decision  support  tools:  View  historical  and  previous  diagnosis  data  for  each  component. 
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Use  Case  7:  Escalate  Diagnosis  from  O-Level  to  1-Level 


Precondition: 

•  Existing  wireless  technology  for  communication  between  the  0-level  and  the  l-level. 

•  Maintenance  person  at  the  O-level  has  failed  to  diagnose  the  problem  with  the  vehicle. 

Actors: 

•  Maintenance  person  at  the  O-level 

Goal: 

To  enlist  help  from  the  l-level  in  diagnosing  a  problem  that  cannot  be  diagnosed  at  the  O-level. 

Flow  of  events: 

1  The  mechanics  at  the  O-level  uploads  sensor  data  stream  and  supplementary  information 
(e.g.  the  breakdown  report),  if  any  to  the  l-level. 

2.  The  information  uploaded  is  stored  in  the  database  for  retrieval  by  the  maintenance  person  at 
the  l-level. 

3.  If  the  mechanics  decides  to  keep  the  vehicle  at  the  O-level,  it  is  tagged  as  awaiting  diagnosis 
from  the  l-level,  and  the  information  is  recorded  in  the  database. 

4.  If  the  mechanics  decides  that  the  faulty  subsystem  should  be  physically  shipped  to  the  l-level, 
the  vehicle  is  tagged  as  awaiting  diagnosis  and  repairs  from  the  l-level,  the  subsystem  is 
physically  sent  to  the  l-level,  and  the  information  is  recorded  in  the  database. 

5.  If  the  mechanics  that  the  vehicle  should  be  physically  shipped  to  the  l-level.  it  is  tagged  as 
awaiting  diagnosis/repairs  from  the  l-level,  sent  to  the  l-level,  and  the  information  is  recorded 
in  the  database. 
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Alternative  Flows: 

None 

Related  Use-Cases: 

Perform  diagnosis  at  O-level 
Perform  diagnosis  at  l-level 

Frequency  and  Levels 

Frequency  of  usage: 

10%  of  frequency  of  use  case  5 

Level  of  operation:  Vehicle  Cl  M4- 

C2  MS 


Data  Implications 


Cl  4  C2:  50k  (vehicle  ID,  date,  time,  problem  description,  prognosis  results,  etc  ) 
C2  Cl:  none 


Algorithms  and  Decision  Support  Tools 

Algorithms  used:  Data  uploads  on  manual  triggers  (Diagnosis  fails  at  O-level) 
Decision  support  tools:  Diagnosis  results  at  O-level 
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Use  Case  8:  Perform  Diagnosis  of  a  Subsystem  at  the  1-Level 


Precondition: 

•  The  O-level  has  escalated  the  diagnosis  to  the  l-level  (see  use  case  “Escalate  diagnosis  to  I- 
level)  i.e,  sensor  data  stream  (for  the  past  24  hours)  and  the  breakdown  report,  if  any,  have 
been  uploaded  to  the  l-level 

•  It  is  possible  that  the  vehicle  or  the  subsystem  have  also  been  shipped  to  the  l-level  though 
this  is  not  necessary  because  the  O-level  may  be  simply  waiting  for  diagnosis  to  be  sent  back 
to  them  so  they  can  perform  the  maintenance. 

Actors: 

•  Maintenance  person  at  l-level 
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Goal: 

•  To  diagnose  the  health  of  a  subsystem  of  an  vehicle  based  on  information  received  from  the 
vehicle  (either  uploaded  data  stream  or  reported  breakdown  from  the  vehicle  operator)  to 
determine  component  failure,  because  it  was  not  possible  to  perform  the  diagnosis  at  the  O- 
level  and  the  l-level  may  have  additional  facilities  to  perform  diagnosis 

Flow  of  events: 

7.  The  maintenance  person  at  the  l-level  retrieves  vehicle  and  subsystem  information  from  the 
database  (see  precondition  above,  which  indicates  the  use  case,  which  has  previously 
populated  the  database). 

8.  The  maintenance  person  at  the  l-level  studies  the  information  received  from  the  O-level  to 
determine  the  nature  of  problem  (diagnosis)  and  resolution  measures 

9  The  maintenance  person  sends  the  diagnosis  results  to  the  O-level  and  this  use  case  stops. 

10.  If  he  is  unable  to  diagnose,  he  triggers  the  use  case  “Escalate  diagnosis  from  l-level  to  D- 
level  (including  sea-base)2  and  this  use  case  stops. 

Alternative  Flow  1 : 

2.  If  the  vehicle  or  the  subsystem  was  also  physically  shipped,  the  maintenance  person  at  the  I- 
level  performs  a  physical  inspection,  called  a  Limited  Technical  Inspection  (LTI),  which  is 
stored  into  the  database. 

3.  The  maintenance  person  at  the  l-level  studies  the  information  received  from  the  O-level  along 
with  the  LTI  performed  in  the  previous  step  to  determine  the  nature  of  problem  (diagnosis) 
and  resolution  measures. 

4.  If  he  is  unable  to  diagnose,  he  triggers  the  use  case  "Escalate  diagnosis  from  l-level  to  D- 
level  (including  sea-base)”  and  this  use  case  stops. 

5.  If  the  diagnosis  is  successful,  the  maintenance  person  triggers  use  case:  "Trigger 
maintenance  action  at  l-level " 

6.  System  records  the  action  in  database,  and  tags  the  vehicle  as  ‘waiting  for  maintenance  ’ 

Related  Use-Cases: 

•  Escalate  diagnosis  from  O-level  to  l-level 

•  Escalate  diagnosis  from  l-level  to  D-level 

•  Trigger  maintenance  action  by  I  level 

Frequency  and  Levels 

Frequency  of  usage:  TBD 

One  breakdown  per  vehicle  per  week 

Level  of  operation:  Vehicle  Cl  Ml 

C2  M2 

C3  M3 


Data  Implications 

C2  M2:  20k  (processed  information  for  the  vehicle) 
M2  C2:  20k  (ERO  description) 


Algorithms  and  Decision  Support  Tools 

Algorithms  used:  Database  updates  on  entering  of  action  taken. 

Decision  support  tools:  View  historical  and  previous  diagnosis  data  for  each  component 
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Use  Case  9:  Escalate  Diagnosis  from  1-Level  to  D-Level 


Precondition: 

•  Existing  wireless  technology  for  communication  between  the  l-level  and  the  D-level. 

•  Maintenance  person  at  the  O-level  has  failed  to  diagnose  the  problem  with  the  vehicle. 

Actors: 

•  Maintenance  analyst  at  l-level 

Goal:  To  enlist  help  from  the  D-level  in  diagnosing  a  problem  that  cannot  be  diagnosed  at  the  I- 

level. 

Flow  of  events: 

1  The  maintenance  analyst  at  the  l-level  uploads  sensor  data  stream  and  supplementary 
information  (e  g.  the  breakdown  report),  if  any  to  the  l-level 

2.  The  information  uploaded  is  stored  in  the  database  for  retrieval  by  the  maintenance  analyst  at 
the  D-level. 

3.  If  the  maintenance  analyst  decides  to  keep  the  vehicle  at  the  l-level,  it  is  tagged  as  awaiting 
diagnosis  from  the  D-level,  and  the  information  is  recorded  in  the  database. 

4  If  the  maintenance  analyst  decides  that  the  faulty  subsystem  should  be  physically  shipped  to 
the  D-level,  the  vehicle  is  tagged  as  awaiting  diagnosis  and  repairs  from  the  D-level,  the 
subsystem  is  physically  sent  to  the  D-level,  and  the  information  is  recorded  in  the  database. 

5.  If  the  maintenance  analyst  decides  that  the  vehicle  should  be  physically  shipped  to  the  D- 
level,  it  is  tagged  as  awaiting  diagnosis/repairs  from  the  D-level,  sent  to  the  D-level,  and  the 
information  is  recorded  in  the  database. 

Alternative  Flows: 
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None 

Related  Use-Cases:  Diagnosis  of  subsystem  at  l-level,  Diagnosis  of  subsystem  at  D-level 

Frequency  and  Levels 

Frequency  of  usage: 

10%  of  frequency  of  use  case  8:”Performs  diagnosis  of  a  subsystem  at  the  l-level” 

Level  of  operation:  Vehiole  Cl  Ml 

C2  MS 

C3  M3 

Data  Implications 

C2  C3:  50k  (vehicle  ID,  date,  time,  problem  description,  prognosis  results,  etc.) 

C3  C2:  none 

Algorithms  and  Decision  Support  Tools 

Algorithms  used:  Data  uploads  on  manual  triggers  (Diagnosis  fails  at  I  level) 

Decision  support  tools:  Diagnosis  results  at  I  level 

Algorithms  and  Decision  Support  Tools 

Algorithms  used:  Data  uploads  on  manual  triggers  (Diagnosis  fails  at  l-level) 

Decision  support  tools:  Diagnosis  results  at  l-level 
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Use  Case  10:  Perform  Diagnosis  of  a  Subsystem  at  the  D-Level 


Precondition: 

•  The  I  level  has  escalated  the  diagnosis  to  the  D  level  (see  use  case  “Escalate  diagnosis  to  D- 
level)  i.e.  sensor  data  stream  (for  the  past  24  hours)  and  the  breakdown  report,  if  any,  have 
been  uploaded  to  the  l-level 

•  It  is  possible  that  the  vehicle  or  the  subsystem  have  also  been  shipped  to  the  D-level  though 
this  is  not  necessary  because  the  Battalion  level  may  be  simply  waiting  for  diagnosis  to  be 
sent  back  to  them  so  they  can  perform  the  maintenance. 

Actors: 

•  Maintenance  person  at  D-level 

Goal: 
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•  To  diagnose  the  health  of  a  subsystem  of  an  vehicle  based  on  information  received  from  the 
vehicle  (either  uploaded  data  stream  or  reported  breakdown  from  the  vehicle  operator)  to 
determine  component  failure,  because  it  was  not  possible  to  perform  the  diagnosis  at  the  I- 
level  and  the  D-level  may  have  additional  facilities  to  perform  diagnosis 

Flow  of  events: 

11  The  maintenance  person  at  the  D-level  retrieves  vehicle  and  subsystem  information  from  the 
database  (see  precondition  above,  which  indicates  the  use  case,  which  has  previously 
populated  the  database). 

12.  The  maintenance  person  at  the  D-level  studies  the  information  received  from  the  l-level  to 
determine  the  nature  of  problem  (diagnosis)  and  resolution  measures. 

13.  The  maintenance  person  sends  the  diagnosis  results  to  the  l-level  and  this  use  case  stops 

Alternative  Flow  1: 

7  If  the  vehicle  or  the  subsystem  was  also  physically  shipped,  the  maintenance  person  at  the 
D-level  performs  a  physical  inspection,  called  a  Limited  Technical  Inspection  (LTI),  which  is 
stored  into  the  database. 

8.  The  maintenance  person  at  the  D-level  studies  the  information  received  from  the  l-level  along 
with  the  LTI  performed  in  the  previous  step  to  determine  the  nature  of  problem  (diagnosis) 
and  resolution  measures. 

9.  If  the  diagnosis  is  successful,  the  maintenance  person  triggers  use  case:  “Trigger 
maintenance  action  at  D-level.” 

10.  System  records  the  action  in  database,  and  tags  the  vehicle  as  ‘waiting  for  maintenance.’ 

Related  Use-Cases: 

•  Escalate  diagnosis  from  l-level  to  D-level 

•  Trigger  maintenance  action  by  D  level 

Frequency  and  Levels 

Frequency  of  usage:  TBD 

1 0%  of  frequency  of  use  case  8:nPerforms  diagnosis  of  a  subsystem  at  the  l-level” 

Level  of  operation:  Vehicle  Cl  Ml 

G3 - m 

C3  m 


Data  Implications 

C3;  none 

Algorithms  and  Decision  Support  Tools 

Algorithms  used:  Database  updates  on  entering  of  action  taken 

Decision  support  tools:  View  historical  and  previous  diagnosis  data  for  each  component. 
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Use  Case  11:  Perform  Prognosis  of  the  Health  of  a  Subsystem  at  O-Level 


Precondition: 

•  Sensor  data  stream  of  a  vehicle  (for  the  past  24  hours)  has  been  uploaded  to  the  O-level 

Actors: 

•  Maintenance  analyst  at  O-level 

Goal: 

•  To  attempt  to  prognostic  the  health  of  a  vehicle  subsystem  based  on  subsystem  sensor  data 
stream  that  has  been  recorded  into  the  database  in  the  past  24  hours. 

Flow  of  events: 

14.  The  maintenance  analyst  at  the  O-level  retrieves  vehicle  and  subsystem  information  from  the 
database. 

15.  The  system  processor  checks  database  to  determine  critical  parameters  and  failure  range  for 
the  sub  system. 

16.  The  system  processor  extracts  appropriate  critical  parameters  from  sensor  data  stream. 

17.  The  system  processor  checks  if  extracted  parameters  fall  in  failure  range. 

18.  If  extracted  parameters  fall  in  failure  range;  the  system  processor  alerts  the  O-level 
mechanic. 

19.  The  system  processor  time  stamps  sensor  data  stream  reception  and  records  it  as  well  as 
other  messages  e.g.  threshold  breach,  mechanic  alert  etc.  in  the  central  database. 

Alternative  Flows: 

5.  If  extracted  parameters  do  not  fall  in  failure  range;  the  system  processor  continues  recording 

data  stream 
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Related  Use-Cases: 

•  Periodically  upload  sensor  data  from  black  box  in  each  vehicle 

•  Perform  diagnosis  of  a  subsystem  at  the  O-level 

Frequency  and  Levels 

Frequency  of  usage: 

Once  a  day 

Level  of  operation:  Vehiole  Cl  M4 

G3 — m 


Data  Implications 

Cl  none 

Algorithms  and  Decision  Support  Tools 

Algorithms  used:  Threshold  detection  in  subsystem  sensor  data  stream,  Data  stream  storage  in 
LAV  database,  Database  search  and  retrieval  of  subsystem  details,  Extraction  of  critical 
parameters  from  sensor  data  stream 

Decision  support  tools:  Visual  representations  of  the  critical  parameters  being  monitored  in  the 
sensor  data  stream  (Front  end)  and  other  subsystem  details  to  vehicle  mechanic,  Alert  to  vehicle 
mechanic  when  breach  occurs 
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Use  Case  12:  Initiate  CBM  by  Filling  the  ERO  at  the  O-Level 


Precondition: 

•  Prognosis  of  a  subsystem  has  been  performed  at  the  battalion  level,  it  has  been  determined 
repairs  will  be  performed  (see  use  case  “Do  prognostic  of  a  subsystem  at  the  battalion  level”), 
and  the  information  has  been  stored  in  the  database. 

Actors: 

.  Maintenance  person  at  the  O-level 

Goal: 

•  To  initiate  condition-based  maintenance  based  on  prognosis  results. 

Flow  of  events: 

20.  The  maintenance  person  at  the  Battalion  level  retrieves  information  about  the  vehicle  and  the 
prognosis  from  the  database  (see  use  case  completed  in  the  precondition) 

21.  The  maintenance  person  opens  a  new  Equipment  Repair  Order  (ERO)  for  the  work  to  be 
performed  based  on  the  diagnosis. 

22.  A  new  ERO  is  created  in  the  database. 

23.  The  maintenance  person  determines  what  work  must  be  performed  based  on  the  prognosis 
and  enters  the  status  and  code  for  each  item  of  work  to  be  performed.  Additional  information 
required  for  the  ERO  is  also  entered. 

24  The  information  is  stored  in  the  database 

25.  The  maintenance  person  checks  the  inventory  and  manpower  available  to  him  at  the  O-level. 

26.  The  maintenance  person  enters  the  SM&R  code  to  indicate  the  characteristic  of  maintenance 
that  need  to  be  performed. 

27.  If  either  the  parts  or  the  tools  or  the  manpower  are  not  available,  he  triggers  futuristic 
scenarios  for  collaborating  with  neighboring  Battalions  or  the  FSSG  (reported  elsewhere). 

28.  Based  on  the  results  of  the  previous  step,  the  maintenance  person  fills  out  the  ERO 
Shopping  List  (EROSL)  for  parts  that  must  be  acquired  for  performing  the  maintenance 
action  The  EROSL  is  created  and  stored  in  the  database. 

Related  Use-Cases: 

•  Do  prognostic  of  a  subsystem  at  I  level 

Frequency  and  Levels 

Frequency  of  usage: 

10%  of  frequency  for  use  case  1 1 :  “Perform  prognosis  of  the  health  of  a  subsystem  at  O-level” 

Level  of  operation:  Vehicle  Cl  Ml 

C2  M3 

G3—  m 


Data  Implications 

Cl  Ml :  20k  (prognosis  result  from  database) 

Ml  ->  Cl.  20k  (ERO  description,  ID,  password,  etc.) 

Algorithms  and  Decision  Support  Tools 

Algorithms  used:  None 
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Decision  support  tools:  None 


Use  Case  13:  Perform  Prognosis  of  Subsystem  at  1-Level 


Precondition: 

•  Sensor  data  stream  of  a  vehicle  (for  the  past  24  hours)  has  been  uploaded  to  the  l-level 

Actors: 

•  Maintenance  analyst  at  I  level 

Goal: 

•  To  attempt  to  prognostic  the  health  of  a  vehicle  subsystem  based  on  subsystem  sensor  data 
stream  that  has  been  recorded  into  the  database  in  the  past  24  hours. 

Flow  of  events: 
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29.  The  maintenance  analyst  at  the  l-level  retrieves  vehicle  and  subsystem  information  from  the 
database 

30.  The  system  processor  checks  database  to  determine  critical  parameters  and  failure  range  for 
the  sub  system. 

31.  The  system  processor  extracts  appropriate  critical  parameters  from  sensor  data  stream 

32.  The  system  processor  checks  if  extracted  parameters  fall  in  failure  range. 

33.  If  extracted  parameters  fall  in  failure  range;  vehicle  system  processor  alerts  the  I  level 
mechanic. 

34.  The  system  processor  time  stamps  sensor  data  stream  reception  and  records  it  as  well  as 
other  messages  e  g.  threshold  breach,  mechanic  alert  etc.  in  the  central  database 

Alternative  Flows: 

6.  If  extracted  parameters  do  not  fall  in  failure  range;  the  system  processor  continues  recording 
data  stream 

Related  Use-Cases:  perform  diagnosis  of  a  subsystem  at  the  I  level 

Frequency  and  Levels 

Frequency  of  usage: 

Once  a  day 

Level  of  operation:  Vehicle  Cl  Ml 

C2  M3 

C3  M3 


Data  Implications 


C2:  none 

Algorithms  and  Decision  Support  Tools 

Algorithms  used:  Threshold  detection  in  subsystem  sensor  data  stream,  Data  stream  storage  in 
LAV  database,  Database  search  and  retrieval  of  subsystem  details,  Extraction  of  critical 
parameters  from  sensor  data  stream 

Decision  support  tools:  Visual  representations  of  the  critical  parameters  being  monitored  in  the 
sensor  data  stream  (Front  end)  and  other  subsystem  details  to  LAV  mechanic,  Alert  to  LAV 
mechanic  when  breach  occurs 
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Use  Case  14:  Initiate  CBM  Action  by  Filling  the  ERO  at  1-Level 


Precondition: 

•  Prognosis  of  a  subsystem  has  been  performed  at  I  level,  it  has  been  determined  repairs  will 
be  performed  (see  use  case  "Do  prognostic  of  a  subsystem  at  I  lever),  and  the  information 
has  been  stored  in  the  database. 

Actors: 

•  Maintenance  person  at  the  I  level 

Goal: 

•  To  initiate  condition-based  maintenance  based  on  prognosis  results. 

Flow  of  events: 

35.  The  maintenance  person  at  the  I  level  retrieves  information  about  the  vehicle  and  the 
prognosis  from  the  database  (see  use  case  completed  in  the  precondition) 

36.  The  maintenance  person  opens  a  new  Equipment  Repair  Order  (ERO)  for  the  work  to  be 
performed  based  on  the  diagnosis. 

37  A  new  ERO  is  created  in  the  database. 

38.  The  maintenance  person  determines  what  work  must  be  performed  based  on  the  prognosis 
and  enters  the  status  and  code  for  each  item  of  work  to  be  performed.  Additional  information 
required  for  the  ERO  is  also  entered. 

39.  The  information  is  stored  in  the  database. 

40.  The  maintenance  person  checks  the  inventory  and  manpower  available  to  him  at  the  l-level. 

41  The  maintenance  person  enters  the  SM&R  code  to  indicate  the  characteristic  of  maintenance 

that  need  to  be  performed. 

42.  If  either  the  parts  or  the  tools  or  the  manpower  are  not  available,  he  triggers  futuristic 
scenarios  for  collaborating  with  neighboring  Battalions  or  the  FSSG  (reported  elsewhere). 

43.  Based  on  the  results  of  the  previous  step,  the  maintenance  person  fills  out  the  ERO 
Shopping  List  (EROSL)  for  parts  that  must  be  acquired  for  performing  the  maintenance 
action.  The  EROSL  is  created  and  stored  in  the  database. 

Related  Use-Cases: 

•  Do  prognostic  of  a  subsystem  at  I  level 
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Frequency  and  Levels 

Frequency  of  usage: 

10%  of  frequency  for  use  case  13:  “Perform  prognosis  of  the  health  of  a  subsystem  at  l-level” 

Level  of  operation:  Veh+Gte — G4 —  Ml 

C2  M2 

Data  Implications 

C2  4  M2:  20k  (prognosis  result  from  database) 

M2  -4  C2:  20k  (ERO  description,  ID,  password,  etc.) 

Algorithms  and  Decision  Support  Tools 

Algorithms  used:  None 
Decision  support  tools:  None 
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Use  Case  15:  Perform  Prognosis  of  Subsystem  at  D-Level 


Precondition: 

.  Sensor  data  stream  of  a  vehicle  (for  the  past  24  hours)  has  been  uploaded  to  the  D  level 

Actors: 

•  Maintenance  analyst  at  D  level 

Goal: 

•  To  attempt  to  prognostic  the  health  of  a  vehicle  subsystem  based  on  subsystem  sensor  data 
stream  that  has  been  recorded  into  the  database  in  the  past  24  hours. 

Flow  of  events: 

44.  The  maintenance  analyst  at  the  D  level  retrieves  vehicle  and  subsystem  information  from  the 
database. 

45.  The  system  processor  checks  database  to  determine  critical  parameters  and  failure  range  for 
the  sub  system. 

46.  The  system  processor  extracts  appropriate  critical  parameters  from  sensor  data  stream. 

47.  The  system  processor  checks  if  extracted  parameters  fall  in  failure  range. 

48.  If  extracted  parameters  fall  in  failure  range;  vehicle  system  processor  alerts  the  D  level 
mechanic. 

49.  The  system  processor  time  stamps  sensor  data  stream  reception  and  records  it  as  well  as 
other  messages  e.g.  threshold  breach,  mechanic  alert  etc.  in  the  central  database. 

Alternative  Flows: 

6.  If  extracted  parameters  do  not  fall  in  failure  range;  vehicle  system  processor  continues 
recording  data  stream 

Related  Use-Cases:  Diagnosis  of  subsystem  at  vehicle  level 

Frequency  and  Levels 

Frequency  of  usage: 

Once  a  day 

Level  of  operation:  Vehicle — G1  M4* 

C2  M2 

C3  m 


Data  Implications 


C3:  none 

Algorithms  and  Decision  Support  Tools 

Algorithms  used:  Threshold  detection  in  subsystem  sensor  data  stream,  Data  stream  storage  in 
LAV  database,  Database  search  and  retrieval  of  subsystem  details,  Extraction  of  critical 
parameters  from  sensor  data  stream 
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Decision  support  tools:  Visual  representations  of  the  critical  parameters  being  monitored  in  the 
sensor  data  stream  (Front  end)  and  other  subsystem  details  to  LAV  mechanic,  Alert  to  LAV 
mechanic  when  breach  occurs 


Use  Case  16:  Initiate  CBM  Action  by  Filling  ERO  at  D-Level 


Precondition: 

•  Prognosis  of  a  subsystem  has  been  performed  at  the  D  level,  it  has  been  determined  repairs 
will  be  performed  (see  use  case  “Perform  diagnosis  of  a  subsystem  at  the  battalion  level”), 
and  the  information  has  been  stored  in  the  database. 

Actors: 

•  Maintenance  person  at  the  D  level 

Goal: 

•  To  initiate  condition-based  maintenance  based  on  prognosis  results. 

Flow  of  events: 

50.  The  maintenance  person  at  the  D  level  retrieves  information  about  the  LAV  and  the  diagnosis 
from  the  database  (see  use  case  completed  in  the  precondition) 

51.  The  maintenance  person  opens  a  new  Equipment  Repair  Order  (ERO)  for  the  work  to  be 
performed  based  on  the  diagnosis. 

52.  A  new  ERO  is  created  in  the  database. 

53.  The  maintenance  person  determines  what  work  must  be  performed  based  on  the  prognosis 
and  enters  the  status  and  code  for  each  item  of  work  to  be  performed.  Additional  information 
required  for  the  ERO  is  also  entered. 

54.  The  information  is  stored  in  the  database. 

55.  The  maintenance  person  checks  the  inventory  and  manpower  available  to  him  at  the  D-level. 

56.  The  maintenance  person  enters  the  SM&R  code  to  indicate  the  characteristic  of  maintenance 
that  need  to  be  performed. 

57.  If  either  the  parts  or  the  tools  or  the  manpower  are  not  available,  he  triggers  futuristic 
scenarios  for  collaborating  with  neighboring  Battalions  or  the  FSSG  (reported  elsewhere). 
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58  Based  on  the  results  of  the  previous  step,  the  maintenance  person  fills  out  the  ERO 
Shopping  List  (EROSL)  for  parts  that  must  be  acquired  for  performing  the  maintenance 
action.  The  EROSL  is  created  and  stored  in  the  database. 

Related  Use-Cases: 

•  Do  prognostic  of  a  subsystem  at  I  level 

Frequency  and  Levels 

Frequency  of  usage: 

10%  of  frequency  for  use  case  15:  “Perform  prognosis  of  the  health  of  a  subsystem  at  D-level” 

Level  of  operation;  Vehicle-  €1 - M4- 

£3 - M3 

C3  M3 


Data  Implications 

C3  M3:  20k  (prognosis  result  from  database) 

M3  C3:  20k  (ERO  description,  ID,  password,  etc.) 

Algorithms  and  Decision  Support  Tools 

Algorithms  used:  None 
Decision  support  tools:  None 


137 


Integration  of  Diagnostics  into  Ground  Equipment  Study 


Final  Report 


Use  Case  17:  Direct  Vehicle  Movement 


Precondition: 

•  Prognosis  has  been  performed  on  the  vehicle  (see  use  case  11  “perform  prognosis  of 
subsystem  at  0-level”) 

•  It  has  been  determined  that  CBM  will  be  performed  on  the  vehicle  (See  use  case  12  “Initiate 
CBM  by  filling  the  ERO  at  O-level") 

•  The  vehicle  can  be  stopped  in  the  field  for  repair  or  maintenance. 

Actors: 

•  Maintenance  analyst  at  the  O-level 

•  Maintenance  person  at  the  O-level 

Goal: 

To  direct  a  vehicle  in  the  field  to  a  specific  location  for  anticipated  repairs  prognosis 

Flow  of  events: 

59.  The  maintenance  analyst  at  the  O-level  retrieves  the  ERO  created  by  the  maintenance 
person  (see  use  case  12  “Initiate  CBM  by  filling  the  ERO  at  O-level”) 

60.  If  either  the  parts  or  the  tools  or  the  manpower  are  not  available,  he  triggers  futuristic 
scenarios  for  collaborating  with  neighboring  Battalions  or  the  FSSG  (reported  elsewhere). 

61.  The  maintenance  analyst  chooses  a  location  where  s/he  would  ask  the  vehicle  to  move 
based  on  its  current  location  and  direction  (provided  by  the  system). 
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62,  The  maintenance  analyst  sends  a  message  to  the  vehicle  to  move  to  that  location. 

Related  Use-Cases: 

.  Perform  prognosis  of  a  subsystem  at  the  O-level 

Frequency  and  Levels 

Frequency  of  usage: 

10%  of  frequency  for  use  case  1 1  “Perform  prognosis  of  the  health  of  a  subsystem  at  O-level” 

Level  of  operation:  Vehicle  Cl  Ml 

G2  m 

C3  M3 


Data  Implications 

Vehicle  -4  Cl:  none 

Cl  4  vehicle:  0.5k  (location  name) 

Cl  Ml:  none 

Ml  -4  Cl:  20k  (ERO  description,  ID,  password,  location  to  perform  maintenance  action.) 


Algorithms  and  Decision  Support  Tools 

Algorithms  used:  None 
Decision  support  tools:  None 


139 


Integration  of  Diagnostics  into  Ground  Equipment  Study 


Final  Report 


Use  Case  18:  Dispatch  Crew  and  Resources  for  Repair/Maintenance 


Precondition: 

•  Vehicle  has  been  directed  to  a  location  for  repair  (see  use  case  17:  “direct  vehicle 
movement”). 

Actors: 

•  Maintenance  analyst  at  O-level 

•  Maintenance  person  at  O-level 

Goal: 

To  successfully  perform  the  maintenance  action  based  on  information  given 

Flow  of  events: 

1  The  maintenance  analyst  assigns  the  maintenance  person  to  perform  the  repair 

2.  The  maintenance  person  reads  the  expected  location  of  the  vehicle  from  the  system  (see  use 
case  17:  “direct  vehicle  movement”) 

3.  The  system  alerts  the  maintenance  personnel  and  dispatches  them  to  the  location  along  with 
required  parts  and  tools. 

4.  The  system  records  the  dispatch. 

Alternative  Flows: 

None 

Related  Use-Cases: 

•  Direct  vehicle  movement 

Frequency  and  Levels 

Frequency  of  usage: 

10%  of  frequency  for  use  case  1 1 :  “Perform  prognosis  of  the  health  of  a  subsystem  at  O-level” 

Level  of  operation:  Vehicle  Cl  Ml 

- m 

G£ - -m 

Data  Implications 


Cl  Ml .  20k  (the  message  to  the  maintenance  person  at  O-level) 
Ml  ^  Cl  0 

Algorithms  and  Decision  Support  Tools 

Algorithms  used:  None 
Decision  support  tools:  None 
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Use  Case  19:  Initiate  Repairs  of  Vehicle  at  O-Level 


Precondition: 

•  Diagnosis  of  a  subsystem  has  been  performed  at  the  O-level,  it  has  been  determined  repairs 
will  be  performed  (see  use  case  "Perform  diagnosis  of  a  subsystem  at  the  O-level”),  and  the 
information  has  been  stored  in  the  database, 

Actors: 

.  Maintenance  person  at  the  O-level 

Goal: 

•  To  successfully  inspect  the  problems  that  occurs  in  the  vehicle  and  fills  the  problem  into  the 
ERO  form. 

Flow  of  events: 

63.  The  maintenance  person  at  the  O-level  retrieves  information  about  the  vehicle  and  the 
diagnosis  from  the  database  (see  use  case  completed  in  the  precondition) 

64.  The  maintenance  person  opens  a  new  Equipment  Repair  Order  (ERO)  for  the  work  to  be 
performed  based  on  the  diagnosis.  A  new  ERO  is  created  in  the  database. 

65.  The  maintenance  person  determines  what  work  must  be  performed  based  on  the  diagnosis 
and  enters  the  status  and  code  for  each  item  of  work  to  be  performed.  Additional  information 
required  for  the  ERO  is  also  entered  The  information  is  stored  in  the  database 

66.  The  maintenance  person  checks  the  inventory  and  manpower  available  to  him  at  the  O-level. 

67.  The  maintenance  person  enters  the  SM&R  code  to  indicate  the  characteristic  of  maintenance 
that  need  to  be  performed. 

68.  If  either  the  parts  or  the  tools  or  the  manpower  are  not  available,  he  triggers  futuristic 
scenarios  for  collaborating  with  neighboring  O-level  or  the  FSSG  (reported  elsewhere). 

69.  Based  on  the  results  of  the  previous  step,  the  maintenance  person  fills  out  the  ERO 
Shopping  List  (EROSL)  for  parts  that  must  be  acquired  for  performing  the  maintenance 
action.  The  EROSL  is  created  and  stored  in  the  database. 

Related  Use-Cases: 

•  Perform  diagnosis  of  a  subsystem  at  the  O-level 

Frequency  and  Levels 
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Frequency  of  usage: 

90%  of  use  case  6  (perform  diagnosis  of  subsystem  at  O-level) 

Level  of  operation:  Vohiclo  Cl  Ml 

G2 - M3 

G3 - m 

Data  Implications 

Cl  Ml:  20k  (diagnosis  result  from  database) 

Ml  Cl  20k  (ERO  description,  ID,  password,  etc.) 

Algorithms  and  Decision  Support  Tools 

Algorithms  used: 

Decision  support  tools: 
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Use  Case  20:  Perform  Maintenance  Action  at  the  O-Level 


Precondition: 

•  The  problem  at  the  vehicle  has  been  diagnosed  either  at  the  O-level  (see  use  case  “Perform 
diagnosis  at  O-level”)  or  a  level  above  (see  use  case  “Perform  diagnosis  at  the  l-level”) 

.  The  maintenance  person  has  already  filled  the  ERO  and  specified  the  characteristic  of  the 
maintenance  to  be  performed  by  filling  the  SM&R  code  (see  use  case  19:  “initiate  repair  of 
vehicle  at  O  level") 

Actors: 

•  Maintenance  personnel  at  the  0  level 

Goal: 

To  successfully  perform  the  maintenance  action  based  on  information  given 

Flow  of  events: 

1.  The  maintenance  person  retrieves  the  diagnosis  result  that  has  been  diagnosed  from  the 
database. 

2  The  maintenance  person  examines  the  information  from  the  LTI  that  has  been  specified 
along  with  MIMMS  codes  prior  the  maintenance  action 

3.  The  maintenance  person  performs  the  maintenance  action  based  on  information  given. 

4.  The  maintenance  person  tags  the  repaired  tag  into  the  vehicle  and  also  fills  the  ERO  form  to 
indicate  the  maintenance  actions  that  has  been  performed 

5  The  system  updates  the  database 

Alternative  Flows: 

None 

Related  Use-Cases: 

•  Initiate  repair  of  vehicle  at  O-level 

Frequency  and  Levels 

Frequency  of  usage: 

Same  as  use  case  19  (initiate  repair  of  vehicle  at  O-level) 

Level  of  operation:  Vehicle  Cl  Ml 

G3 - 443 

G3= — M3 


Data  Implications 

Cl  Ml:  20k  (diagnosis  result  from  database) 

Ml  Cl:  20k  (ERO  description,  ID,  password,  etc  ) 

Algorithms  and  Decision  Support  Tools 

Algorithms  used:  None 
Decision  support  tools:  None 
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Use  Case  21:  Initiate  Repairs  of  Vehicle  at  1-Level 


Precondition: 

•  Diagnosis  of  a  subsystem  has  been  performed  at  the  l-level,  it  has  been  determined  repairs 
will  be  performed  (see  use  case  “Perform  diagnosis  of  a  subsystem  at  the  I  level”),  and  the 
information  has  been  stored  in  the  database 

Actors: 

•  Maintenance  person  at  the  l-level 

Goal: 

•  To  successfully  inspect  the  problems  that  occurs  in  the  vehicle  and  fills  the  problem  into  the 
ERO  form. 

Flow  of  events: 

70.  The  maintenance  person  at  the  I  level  retrieves  information  about  the  vehicle  and  the 
diagnosis  from  the  database  (see  use  case  completed  in  the  precondition) 
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71.  The  maintenance  person  opens  a  new  Equipment  Repair  Order  (ERO)  for  the  work  to  be 
performed  based  on  the  diagnosis.  A  new  ERO  is  created  in  the  database. 

72.  The  maintenance  person  determines  what  work  must  be  performed  based  on  the  diagnosis 
and  enters  the  status  and  code  for  each  item  of  work  to  be  performed  Additional  information 
required  for  the  ERO  is  also  entered.  The  information  is  stored  in  the  database. 

73.  The  maintenance  person  checks  the  inventory  and  manpower  available  to  him  at  the  l-level. 

74.  The  maintenance  person  enters  the  SM&R  code  to  indicate  the  characteristic  of  maintenance 
that  need  to  be  performed. 

75.  If  either  the  parts  or  the  tools  or  the  manpower  are  not  available,  he  triggers  futuristic 
scenarios  for  collaborating  with  neighboring  Battalions  or  the  FSSG  (reported  elsewhere) 

76.  Based  on  the  results  of  the  previous  step,  the  maintenance  person  fills  out  the  ERO 
Shopping  List  (EROSL)  for  parts  that  must  be  acquired  for  performing  the  maintenance 
action.  The  EROSL  is  created  and  stored  in  the  database. 

Related  Use-Cases: 

•  Perform  diagnosis  of  a  subsystem  at  the  I  level 

Frequency  and  Levels 

Frequency  of  usage: 

90%  of  use  case  8  (perform  diagnosis  of  subsystem  at  l-level) 

Level  of  operation:  Vehicle  Cl  M4 

C2  M2 

G3 - m 


Data  Implications 

C2  M2:  20k  (diagnosis  result  from  database) 

M2  C2:  20k  (ERO  description,  ID,  password,  etc.) 

Algorithms  and  Decision  Support  Tools 

Algorithms  used:  None 
Decision  support  tools:  None 
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Use  Case  22:  Perform  Maintenance  Action  at  the  1-Level 


Precondition: 

•  The  problem  at  the  vehicle  has  been  diagnosed  either  at  the  l-level  (see  use  case  “Perform 
diagnosis  at  l-level”)  or  a  level  above  (see  use  case  “Perform  diagnosis  at  the  D-level”) 

•  The  maintenance  person  has  already  filled  the  ERO  and  specified  the  characteristic  of  the 
maintenance  to  be  performed  by  filling  the  SM&R  code  (see  use  case  19:  “initiate  repair  of 
vehicle  at  l-level’1) 

Actors: 

•  Maintenance  person  at  the  l-level 

Goal: 

To  successfully  perform  the  maintenance  action  based  on  information  given 

Flow  of  events: 
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6.  The  maintenance  person  retrieves  the  diagnosis  result  that  has  been  diagnosed  from  the 
database. 

7.  The  maintenance  person  examines  the  information  from  the  LTI  that  has  been  specified 
along  with  MIMMS  codes  prior  the  maintenance  action. 

8  The  maintenance  person  performs  the  maintenance  action  based  on  information  given. 

9  The  maintenance  person  tags  the  repaired  tag  into  the  vehicle  and  also  fills  the  ERO  form  to 
indicate  the  maintenance  actions  that  has  been  performed. 

10.  The  system  updates  the  database 

Alternative  Flows: 

None 

Related  Use-Cases: 

•  Initiate  repair  of  vehicle  at  l-level 

Frequency  and  Levels 

Frequency  of  usage: 

Level  of  operation:  Vehicle  Cl  Ml 

C2  M2 

C3  m 

Data  Implications 

C2  M2:  20k  (diagnosis  result  from  database) 

M2  ->  C2:  20k  (ERO  description,  ID,  password,  etc.) 

Algorithms  and  Decision  Support  Tools 


Algorithms  used:  None 
Decision  support  tools:  None 
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Use  Case  23:  Initiate  Repairs  of  Vehicle  at  D-Level 


Precondition: 

•  Diagnosis  of  a  subsystem  has  been  performed  at  the  D  level,  it  has  been  determined  repairs 
will  be  performed  (see  use  case  “Perform  diagnosis  of  a  subsystem  at  the  D  level”),  and  the 
information  has  been  stored  in  the  database. 

Actors: 

•  Maintenance  person  at  the  D  level 

Goal: 

To  successfully  inspect  the  problems  that  occurs  in  the  vehicle  and  fills  the  problem  into  the  ERO 

form. 

Flow  of  events: 

77.  The  maintenance  person  at  the  Battalion  level  retrieves  information  about  the  vehicle  and  the 
diagnosis  from  the  database  (see  use  case  completed  in  the  precondition) 
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78.  The  maintenance  person  opens  a  new  Equipment  Repair  Order  (ERO)  for  the  work  to  be 
performed  based  on  the  diagnosis.  A  new  ERO  is  created  in  the  database. 

79.  The  maintenance  person  determines  what  work  must  be  performed  based  on  the  diagnosis 
and  enters  the  status  and  code  for  each  item  of  work  to  be  performed.  Additional  information 
required  for  the  ERO  is  also  entered.  The  information  is  stored  in  the  database 

80  The  maintenance  person  checks  the  inventory  and  manpower  available  to  him  at  the  D-level. 

81.  The  maintenance  person  enters  the  SM&R  code  to  indicate  the  characteristic  of  maintenance 
that  need  to  be  performed 

82.  If  either  the  parts  or  the  tools  or  the  manpower  are  not  available,  he  triggers  futuristic 
scenarios  for  collaborating  with  neighboring  Battalions  or  the  FSSG  (reported  elsewhere). 

83.  Based  on  the  results  of  the  previous  step,  the  maintenance  person  fills  out  the  ERO 
Shopping  List  (EROSL)  for  parts  that  must  be  acquired  for  performing  the  maintenance 
action.  The  EROSL  is  created  and  stored  in  the  database. 

Related  Use-Cases: 

•  Perform  diagnosis  of  a  subsystem  at  the  D  level 

Frequency  and  Levels 

Frequency  of  usage: 

Same  as  use  case  10  (perform  diagnosis  of  subsystem  at  D-level) 

Level  of  operation:  Vehicle— &1 — — M4 

S3— — M3 

C3  M3 

Data  Implications 


C3  M3:  20k  (diagnosis  result  from  database) 

M3  C3:  20k  (ERO  description,  ID,  password,  etc.) 

Algorithms  and  Decision  Support  Tools 

Algorithms  used:  None 
Decision  support  tools:  none 
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Use  Case  24:  Perform  Maintenance  Action  at  the  D-Level 


Precondition: 

•  The  problem  at  the  vehicle  has  been  diagnosed  either  at  the  D-level  (see  use  case  “Perform 
diagnosis  at  D-level”) 

.  The  maintenance  person  has  already  filled  the  ERO  and  specified  the  characteristic  of  the 
maintenance  to  be  performed  by  filling  the  SM&R  code  (see  use  case  19:  “initiate  repair  of 
vehicle  at  l-level") 

Actors: 

•  Maintenance  personnel  at  the  D-level 

Goal: 

To  successfully  perform  the  maintenance  action  based  on  information  given 

Flow  of  events: 
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11.  The  maintenance  person  retrieves  the  diagnosis  result  that  has  been  diagnosed  from  the 
database 

12  The  maintenance  person  examines  the  information  from  the  LTI  that  has  been  specified 
along  with  MIMMS  codes  prior  the  maintenance  action. 

13.  The  maintenance  person  performs  the  maintenance  action  based  on  information  given 
14  The  maintenance  person  tags  the  repaired  tag  into  the  vehicle  and  also  fills  the  ERO  form  to 
indicate  the  maintenance  actions  that  has  been  performed. 

15.  The  system  updates  the  database 

Alternative  Flows: 

None 

Related  Use-Cases: 

•  Initiate  repair  of  vehicle  at  D-level 

Frequency  and  Levels 

Frequency  of  usage: 

Same  as  use  case  10  (perform  diagnosis  of  subsystem  at  D-level) 

Level  of  operation:  Vehicle  Cl  - M4 

G3-= — MS 

C3  M3 

Data  Implications 

C3  ->  M3:  20k  (diagnosis  result  from  database) 

M3  C3:  20k  (ERO  description,  ID,  password,  etc.) 

Algorithms  and  Decision  Support  Tools 

Algorithms  used:  None 
Decision  support  tools:  None 
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Use  Case  25:  View  Health  of  a  Vehicle  at  O-Level 


Precondition: 

The  IDGE  system  (at  various  levels)  is  monitoring  the  health  status  of  a  subsystem/component  in 
the  vehicle  and  storing  this  data  in  the  component  history  database  as  well  as  all  the  previous 
diagnosis  results  and  other  component  level  details. 

Actors: 

•  Maintenance  analyst  at  O-level 

•  Commander  of  platoon/company/battalion  in  field 

Goal: 

To  allow  viewing  history  of  a  component  or  subsystem  or  a  vehicle  including  past  diagnosis 
results,  component  specifications  and  other  details.  The  use  case  allows  the  actor  to  move  from 
an  vehicle  perspective  to  a  component  perspective  and  vice  versa. 

Flow  of  events: 
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1  The  actor  logs  into  the  history  database  to  view  history/diagnosis  results. 

2.  System  asks  for  the  vehiclejd. 

3.  The  actor  may  browse  vehicle  id  numbers  displayed  by  the  system. 

4.  Actor  provides  the  vehicle  id  to  the  system  either  by  entering  the  id  or  by  clicking  on  one  of  the 
displayed  id’s. 

5.  System  displays  the  list  of  components/subsystems  along  with  basic  information  within  the 
vehicle  selected. 

6.  Actor  selects  a  component/subsystem  by  clicking  the  desired  component/subsystem. 

7.  System  computes  basic  statistical  measures  (e  g.  averages)  based  on  information  contained  in 
the  database,  as  necessary. 

8.  System  displays  history,  including  diagnoses,  inspection  performed,  vehicle  mileage,  and 
maintenance  performed,  of  that  component/subsystem  along  with  any  basic  statistical  features 
computed  in  the  previous  step. 

Related  Use-Cases: 

View  health  summary  of  vehicle  at  O-level 

Frequency  and  Levels 

Frequency  of  usage: 

Five  times  a  day  for  each  vehicle 

Level  of  operation:  Vehicle  Cl  Ml 

GSr - M3 

£3 — -m 


Data  Implications 

Cl  ->  MT  20k  (diagnosis  result  from  database,  avg.  mean  time  between  failure  of  vehicle,  etc.)/1 
vehicle 

Ml  Cl  0.5k  (ID,  password,  etc.)/1  vehicle 

Algorithms  and  Decision  Support  Tools 

Algorithms  used: 

Database  search  and  retrieval  of  vehicle  component  details 

Decision  support  tools: 

Display  of  results  (Front  end) 
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Use  Case  26:  View  Health  of  a  Vehicle  at  1-Level 


Precondition: 

The  IDGE  system  (at  various  levels)  is  monitoring  the  health  status  of  a  subsystem/component  in 
the  vehicle  and  storing  this  data  in  the  component  history  database  as  well  as  all  the  previous 
diagnosis  results  and  other  component  level  details, 

Actors: 

•  Maintenance  analyst  at  I  level 

•  Commander  of  division/FSSG  in  field 

Goal: 

To  allow  viewing  history  of  a  component  or  subsystem  or  a  vehicle  including  past  diagnosis 
results,  component  specifications  and  other  details.  The  use  case  allows  the  actor  to  move  from 
an  vehicle  perspective  to  a  component  perspective  and  vice  versa. 

Flow  of  events: 

1  The  actor  logs  into  the  history  database  to  view  history/diagnosis  results 

2.  System  asks  for  the  vehicle_id. 

3.  The  actor  may  browse  vehicle  id  numbers  displayed  by  the  system. 

4.  Actor  provides  the  vehicle  id  to  the  system  either  by  entering  the  id  or  by  clicking  on  one  of  the 
displayed  ids. 

5.  System  displays  the  list  of  components/subsystems  along  with  basic  information  within  the 
vehicle  selected. 

6.  Actor  selects  a  component/subsystem  by  clicking  the  desired  component/subsystem. 

7.  System  computes  basic  statistical  measures  (e.g.  averages)  based  on  information  contained  in 
the  database,  as  necessary. 

8.  System  displays  history,  including  diagnoses,  inspection  performed,  vehicle  mileage,  and 
maintenance  performed,  of  that  component/subsystem  along  with  any  basic  statistical  features 
computed  in  the  previous  step. 

Related  Use-Cases: 

View  health  summary  of  vehicle  at  I  level 
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Frequency  and  Levels 


Frequency  of  usage: 

Five  times  a  day  for  each  vehicle 

Level  of  operation:  Vohiclo  Cl  Ml 

C2  M2 

G3 - MS 

Data  Implications 

C2  M2:  20k  (diagnosis  result  from  database,  avg.  mean  time  between  failure  of  vehicle,  etc)/1 
vehicle 

M2  C2:  0.5k  (ID,  password,  etc.)/1  vehicle 

Algorithms  and  Decision  Support  Tools 

Algorithms  used: 

Database  search  and  retrieval  of  vehicle  component  details 

Decision  support  tools: 

Display  of  results  (Front  end) 


Use  Case  27:  View  Health  of  a  Vehicle  at  D-Level 


Precondition: 

The  IDGE  system  (at  various  levels)  is  monitoring  the  health  status  of  a  subsystem/component  in 
the  vehicle  and  storing  this  data  in  the  component  history  database  as  well  as  all  the  previous 
diagnosis  results  and  other  component  level  details. 
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Actors: 

•  Mechanics  at  D  level 

•  Commander  of  brigade 

Goal: 

To  allow  viewing  history  of  a  component  or  subsystem  or  a  vehicle  including  past  diagnosis 
results,  component  specifications  and  other  details.  The  use  case  allows  the  actor  to  move  from  a 
vehicle  perspective  to  a  component  perspective  and  vice  versa. 

Flow  of  events: 

1  The  actor  logs  into  the  history  database  to  view  history/diagnosis  results. 

2.  System  asks  for  the  vehicle_id. 

3.  The  actor  may  browse  vehicle  id  numbers  displayed  by  the  system. 

4.  Actor  provides  the  vehicle  id  to  the  system  either  by  entering  the  id  or  by  clicking  on  one  of  the 
displayed  id's. 

5.  System  displays  the  list  of  components/subsystems  along  with  basic  information  within  the 
vehicle  selected. 

6  Actor  selects  a  component/subsystem  by  clicking  the  desired  component/subsystem 

7  System  computes  basic  statistical  measures  (e.g.  averages)  based  on  information  contained  in 
the  database,  as  necessary. 

8.  System  displays  history,  including  diagnoses,  inspection  performed,  vehicle  mileage,  and 
maintenance  performed,  of  that  component/subsystem  along  with  any  basic  statistical  features 
computed  in  the  previous  step. 

Related  Use-Cases: 

View  health  summary  of  vehicle  at  D  level 

Frequency  and  Levels 

Frequency  of  usage: 

Five  times  a  day  for  each  vehicle 

Level  of  operation:  Vehicle  G 1 . Ml 

G2 - m 

C3  M3 

Data  Implications 

C3  M3:  20k  (diagnosis  result  from  database,  avg.  mean  time  between  failure  of  vehicle.  etc)/1 
vehicle 

M3  C3:  0.5k  (ID,  password,  etc.)/1  vehicle 

Algorithms  and  Decision  Support  Tools 

Algorithms  used: 

Database  search  and  retrieval  of  vehicle  component  details 

Decision  support  tools: 

Display  of  results  (Front  end) 
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Use  Case  28:  View  Health  Summary  of  Vehicle  at  O-Level 

Precondition: 

The  IDGE  system  (at  various  levels)  is  monitoring  the  health  status  of  a  subsystem/component  in 
the  vehicle  and  storing  this  data  in  the  component  history  database  as  well  as  all  the  previous 
diagnosis  results  and  other  component  level  details, 

Actors: 

•  Maintenance  analyst  at  O-level 

•  Commander  of  platoon/company/battalion  in  field 

Goal: 

To  allow  viewing  history  of  a  component  or  subsystem  or  a  vehicle  including  past  diagnosis 
results,  component  specifications  and  other  details.  The  use  case  allows  the  actor  to  move  from  a 
vehicle  perspective  to  a  component  perspective  and  vice  versa. 

Flow  of  events: 

1  The  actor  logs  into  the  history  database  to  view  history/diagnosis  results 

2.  System  asks  for  the  component/subsystem  id. 

3.  The  actor  may  browse  component/subsystem  id  numbers  and  descriptions  displayed  by  the 
system. 

4.  Actor  provides  the  component/subsystem  id  to  the  system  either  by  entering  the  id  or  by 
clicking  on  one  of  the  displayed  id’s. 

5.  System  displays  summary  information  about  all  instances  of  that  component/subsystem  that 
are  currently  installed. 

6.  If  additional  history  is  needed,  the  system  prompts  the  Actor  to  enter  a  period  (e  g.  last  month, 
last  quarter,  last  year  etc.) 

7.  System  computes  basic  statistical  measures  based  on  information  contained  in  the  database, 
as  necessary, 

8.  System  displays  summary  information  (history,  including  diagnoses,  inspection  performed,  and 
maintenance  performed)  including  basic  statistical  measures  about  all  instances  of  that 
component/subsystem  over  the  period  selected  by  the  actor. 

Related  Use-Cases: 


157 


Integration  of  Diagnostics  into  Ground  Equipment  Study 


Final  Report 


View  health  of  a  vehicle  at  O-level 

Frequency  and  Levels 

Frequency  of  usage: 

Five  times  a  day  for  each  vehicle 

Level  of  operation:  Vehicle  Cl  Ml 

G2 - m 

C3 - m 


Data  Implications 

Cl  Ml:  20k  (diagnosis  result  from  database,  avg.  days  of  maintenance  performance  etc. )/1 
vehicle 

Ml  Cl  0.5k  (ID,  password,  etc.)/1  vehicle 

Algorithms  and  Decision  Support  Tools 

Algorithms  used: 

Database  search  and  retrieval  of  vehicle  component  details 

Decision  support  tools: 

Display  of  results  (Front  end) 


Use  Case  29;  View  Health  Summary  of  Vehicle  at  1-Level 

Precondition: 
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The  IDGE  system  (at  various  levels)  is  monitoring  the  health  status  of  a  subsystem/component  in 
the  vehicle  and  storing  this  data  in  the  component  history  database  as  well  as  all  the  previous 
diagnosis  results  and  other  component  level  details. 

Actors: 

•  Maintenance  analyst  at  I  level 

•  Commander  of  division/FSSG  in  field 

Goal: 

To  allow  viewing  history  of  a  component  or  subsystem  or  a  vehicle  including  past  diagnosis 
results,  component  specifications  and  other  details.  The  use  case  allows  the  actor  to  move  from  a 
vehicle  perspective  to  a  component  perspective  and  vice  versa. 

Flow  of  events: 

1.  The  actor  logs  into  the  history  database  to  view  history/diagnosis  results. 

2  System  asks  for  the  component/subsvstem  id. 

3.  The  actor  may  browse  component/subsystem  id  numbers  and  descriptions  displayed  by  the 
system. 

4.  Actor  provides  the  component/subsystem  id  to  the  system  either  by  entering  the  id  or  by 
clicking  on  one  of  the  displayed  ids 

5.  System  displays  summary  information  about  all  instances  of  that  component/subsystem  that 
are  currently  installed. 

6.  If  additional  history  is  needed,  the  system  prompts  the  Actor  to  enter  a  period  (e  g.  last  month, 
last  quarter,  last  year  etc.) 

7.  System  computes  basic  statistical  measures  based  on  information  contained  in  the  database, 
as  necessary. 

8.  System  displays  summary  information  (history,  including  diagnoses,  inspection  performed,  and 
maintenance  performed)  including  basic  statistical  measures  about  all  instances  of  that 
component/subsystem  over  the  period  selected  by  the  actor. 

Related  Use-Cases: 

View  health  of  a  vehicle  at  I  level 

Frequency  and  Levels 

Frequency  of  usage: 

Once  a  day  for  each  vehicle 

Level  of  operation:  VehiGte  C4  — M4> 

C2  M2 

G3  M3 


Data  Implications 

C2  M2:  20k  (diagnosis  result  from  database,  avg.  days  of  maintenance  performance  etc.)/1 
vehicle 

M2  C2:  0.5k  (ID,  password,  etc.)/1  vehicle 

Algorithms  and  Decision  Support  Tools 

Algorithms  used: 

Database  search  and  retrieval  of  vehicle  component  details 

Decision  support  tools: 

Display  of  results  (Front  end) 


159 


Integration  of  Diagnostics  into  Ground  Equipment  Study 


Final  Report 


Use  Case  30:  View  Health  Summary  of  Vehicle  at  D-Level 


Precondition: 

The  IDGE  system  (at  various  levels)  is  monitoring  the  health  status  of  a  subsystem/component  in 
the  vehicle  and  storing  this  data  in  the  component  history  database  as  well  as  all  the  previous 
diagnosis  results  and  other  component  level  details. 

Actors: 

•  Mechanics  at  D  level 

•  Commander  of  brigade 

Goal: 

To  allow  viewing  history  of  a  component  or  subsystem  or  a  vehicle  including  past  diagnosis 
results,  component  specifications  and  other  details.  The  use  case  allows  the  actor  to  move  from 
an  vehicle  perspective  to  a  component  perspective  and  vice  versa. 

Flow  of  events: 

1.  The  actor  logs  into  the  history  database  to  view  history/diagnosis  results. 

2.  System  asks  for  the  component/subsystem  id. 

3.  The  actor  may  browse  component/subsystem  id  numbers  and  descriptions  displayed  by  the 
system. 

4.  Actor  provides  the  component/subsystem  id  to  the  system  either  by  entering  the  id  or  by 
clicking  on  one  of  the  displayed  ids. 

5.  System  displays  summary  information  about  all  instances  of  that  component/subsystem  that 
are  currently  installed. 

6.  If  additional  history  is  needed,  the  system  prompts  the  Actor  to  enter  a  period  (eg  last  month, 
last  quarter,  last  year  etc.) 

7.  System  computes  basic  statistical  measures  based  on  information  contained  in  the  database, 
as  necessary. 
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8.  System  displays  summary  information  (history,  including  diagnoses,  inspection  performed,  and 
maintenance  performed)  including  basic  statistical  measures  about  all  instances  of  that 
component/subsystem  over  the  period  selected  by  the  actor. 

Related  Use-Cases: 

View  health  of  a  vehicle  at  D  level 

Frequency  and  Levels 

Frequency  of  usage: 

Five  times  a  day  for  each  vehicle 

Level  of  operation:  Vehicle  Cl  Ml 

G3 - MS 

C3  M3 


Data  Implications 

C3  4  M3:  20k  (diagnosis  result  from  database,  avg.  days  of  maintenance  performance  etc.)/1 
vehicle 

M3  -4  C3:  0.5k  (ID,  password,  etc.)/1  vehicle 

Algorithms  and  Decision  Support  Tools 

Algorithms  used: 

Database  search  and  retrieval  of  LAV  component  details 

Decision  support  tools: 

Display  of  results  (Front  end) 
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Use  Case  31 :  Trigger  Request  Management 


Precondition: 

The  mechanics  at  particular  maintenance  level  checks  the  availability  of  the  component  that 
needs  to  be  repaired  or  changed. 

Actors: 

•  Maintenance  person  at  O  level 

•  Maintenance  person  at  I  level 

•  Maintenance  person  at  D  level 

•  Request  Management  Manager 

Goal:  To  support  the  needs  of  components  by  the  mechanics  at  a  particular  level  of 
maintenance. 

Flow  of  events 

1.  The  mechanic  in  particular  maintenance  level  check  the  availability  of  the  component  in  the 
warehouse  or  through  the  component  availability  database 

2.  If  (component  =  available)  the  mechanic  takes  the  component  from  the  warehouse  and 
update  the  remaining  number  of  components  into  the  inventory  database. 

Alternative  Flows: 

2.  If  (component  =  unavailable)  the  mechanic  requests  for  the  component  online  to  the  Request 
Management  Manager. 

3.  The  Request  Management  Manager  updates  the  order  activity  into  the  inventory  database. 

Related  Use  Cases: 

Perform  maintenance  actions  at  O,  I,  and  D  level 

Frequency  and  Levels 

Frequency  of  usage:  (to  be  determined  based  on  how  the  futuristic  scenario  are  implemented. 
Therefore,  this  is  not  part  of  the  data  implication  analysis) 

Level  of  operation:  Vehiolo  C1»  Ml 

02  M2 

02  M3 


Data  Implications 

Ml,  M2,  M3:  (to  be  determined  based  on  how  the  futuristic  scenario  are  implemented.  Therefore, 
this  is  not  part  of  the  data  implication  analysis) 

Algorithms  and  Decision  Support  Tools 

Algorithm  Used:  request  for  the  availability  of  the  component,  upload  the  remain  number  of  the 
component  into  the  inventory  database 

Decision  Support  Tools:  display  the  availability  of  the  particular  component  at  particular  level 
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8.4.2  Aggregate  Data  Transmission  Implications 

The  following  represents  the  aggregate  data  transmission  implications  if  the  use 
cases  are  implemented  as  envisioned  and  are  used  with  frequencies  suggested 
by  the  interviewees.  The  data  implications  below  represent  aggregates  for  each 
day.  The  notation  used  in  the  table  below  mirrors  the  levels  we  have  identified  in 
each  use  case:  Cl  through  C3,  Ml  through  M3  and  the  vehicle  level.  These  in 
turn  capture  the  three  echelons  of  maintenance  and  are  further  described  in 
Section  4.1 .5  of  this  final  report. 


From 

To 

Total 

(kb) 

Vehicle 

Cl 

20040 

Cl 

Vehicle 

2 

Cl 

Ml 

140 

Ml 

Cl 

101 

Cl 

C2  50 

C2 

Cl 

0 

C2 

M2 

120 

M2 

C2 

81 

C2 

C3 

50 

C3 

C2 

0 

C3 

M3 

100 

M3 

C3 

61 
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The  intermediate  products  that  lead  to  the  above  aggregated  data  requirements 
are  shown  below  as  a  spreadsheet.  The  spreadsheet  with  the  computation 
formulae  is  available  as  an  attachment  to  this  final  report  as  file  name: 
computinq-data-aqqreqates.xls 


Use 

case 

# 

Use  case  name 

From 

To 

Size  of 
data 
(kb) 

Frequency/day 

size  of 
fleet 

1 

Record  from  sensor 
and  store  in  black  box 

Vehicle 

Vehicle 

21600 

1 

100 

100 

2 

Query  a  sensor 

Vehicle 

Cl 

20 

0.1 

100 

Cl 

Vehicle 

i 

100 

3 

Periodically  upload 
sensor  data  from  black 
box  in  each  vehicle 

Vehicle 

Cl 

20000 

1 

100 

Cl 

Vehicle 

0.5 

100 

4 

Report  a  breakdown 

Vehicle 

Cl 

20 

0.14 

100 

Cl 

Vehicle 

0 

100 

5 

Process  a  breakdown 
report  at  O-level 

Cl 

Cl 

0.14 

100 

100 

6 

Perform  diagnosis  of  a 
subsystem  at  the  0- 
level 

Cl 

Ml 

20 

0.14 

100 

Ml 

Cl 

20 

100 

7 

Escalate  diagnosis  from 
O-level  to  l-level 

Cl 

C2 

50 

0.014 

100 

C2 

Cl 

0 

100 

8 

Perform  diagnosis  of  a 
subsystem  at  the  l-level 

C2 

M2 

20 

0.014 

100 

M2 

C2 

20 

100 

9 

Escalate  diagnosis  from 
l-level  to  D-level 

C2 

C3 

50 

0.0014 

100 

C3 

C2 

0 

100 

10 

Perform  diagnosis  of  a 
subsystem  at  the  D- 
level 

C2 

C2 

0 

0.0014 

100 

100 

11 

Perform  prognosis  of 
subsystem  at  O-level 

Cl 

Cl 

0 

1 

100 

100 

12 

Initiate  CBM  by  filling 
the  ERO  at  O-level 

Cl 

Ml 

20 

0.1 

100 

Ml 

Cl 

20 

100 

13 

Perform  prognosis  of 
subsystem  at  l-level 

C2 

C2 

0 

1 

100 

100 

14 

Initiate  CBM  by  filling 
the  ERO  at  l-level 

C2 

M2 

20 

0.1 

100 

M2 

C2 

20 

100 

15 

Perform  prognosis  of 
subsystem  at  D-level 

C3 

1 

100 

100 

16 

Initiate  CBM  by  filling 
the  ERO  at  D-level 

C3 

M3 

20 

0.1 

100 

M3 

C3 

20 

100 

17 

Direct  vehicle 

Vehicle 

Cl 

0 

0.1 

100 
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Use 

case 

# 

Use  case  name 

From 

To 

Size  of 
data 
(kb) 

Frequency/day 

size  of 
fleet 

movement 

Cl 

Vehicle 

0.5 

100 

Cl 

Ml 

0 

100 

Ml 

Cl 

20 

100 

18 

Dispatch  maintenance 
crew  and  resources  for 
preventive  repair  and 
maintenance 

Cl 

Ml 

20 

0.1 

100 

Ml 

Cl 

0 

100 

19 

Initiate  repair  of  vehicle 
at  O-level 

Cl 

Ml 

20 

0.13 

100 

Ml 

Cl 

20 

100 

20 

Perform  maintenance 
action  at  O-level 

Cl 

Ml 

20 

0.13 

100 

Ml 

Cl 

20 

100 

21 

Initiate  repair  of  vehicle 
at  l-level 

C2 

M2 

20 

0.0129 

100 

M2 

C2 

20 

100 

22 

Perform  maintenance 
action  at  l-level 

C2 

M2 

20 

0.0129 

100 

M2 

C2 

20 

100 

23 

Initiate  repair  of  vehicle 
at  D-level 

C3 

M3 

20 

0.0014 

100 

M3 

C3 

20 

100 

24 

Perform  maintenance 
action  at  D-level 

C3 

M3 

20 

0.0014 

100 

M3 

C3 

20 

100 

25 

View  health  of  vehicle 
at  O-level 

Cl 

Ml 

20 

5 

100 

Ml 

Cl 

0.5 

100 

26 

View  health  of  vehicle 
at  l-level 

C2 

M2 

20 

5 

100 

M2 

C2 

0.5 

100 

27 

View  health  of  vehicle 
at  D-level 

C3 

M3 

20 

5 

100 

M3 

C3 

0.5 

100 

28 

View  health  summary  of 
vehicle  at  O-level 
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8.5  Review  of  Prognostics  and  Health  Management  Systems 

Robust  diagnostic  systems  for  complex  mechanical  systems  have  been  the  focus 
of  an  enormous  amount  of  research  over  the  past  30  years.  Turbo-shaft 
engines,  transmissions,  and  lubrication  systems  are  simply  a  few  examples  of 
targeted  applications  of  CBM  technology.  A  review  of  current  health  monitoring 
and  diagnostic  systems  has  shown  that  military  applications  are  the  driving  force 
behind  the  majority  of  current  research  and  development  in  this  area. 

In  1997  the  US  Army’s  General  Officer  Steering  Committee,  anchored  by 
a  three-star  general,  directed  the  establishment  of  a  strategy  now  known  as  the 
Army  Diagnostic  Improvement  Plan  (ADIP)  that  supports  a  variety  of  Army-wide 
initiatives,  including  Army  After  Next,  Force  XXI,  Joint  Vision  2010  and  Global 
Combat  Support  System  -  Army  [1],  The  improvement  plan  consists  of  three 
basic  thrusts,  outlined  below. 

1 .  (Near-term)  Target  legacy  platforms  with  existing  monitoring  capabilities 
for  the  incorporation  of  diagnostic  systems, 

2.  (Mid-term)  Transition  to  anticipatory  maintenance  system  via  enhanced 
maintenance/logistics  automation  technologies,  and 

3.  (Long-term)  Full  prognostic  maintenance  capability  designed  into  future 
combat  systems. 

The  ADIP  vision  involves  wireless  sensor  technology  that  provides  real-time 
connectivity  of  critical  combat  systems  to  the  logistical  framework  of  the  Army, 
providing  an  anticipatory  maintenance  and  logistic  capability.  While  this  plan 
advocates  portable  diagnostic  equipment  for  maintainers,  such  as  the  Soldier’s 
Portable  On-system  Repair  Tool  (SPORT)  and  the  Aviation  Turbine  Engine 
Diagnostic  System  (ATEDS),  it  is  more  focused  on  the  development  of 
embedded  diagnostic  systems.  These  systems  incorporate  technical  manuals 
and  other  maintenance  tools  in  an  interactive  electronic  format,  Systems  that 
have  already  been  targeted  include  the  AH-64D  Apache,  the  UH-60A/L 
Blackhawk,  the  CH-47F  Chinook,  the  M1A2  Abrams,  the  M2A3  Bradley  Fighting 
Vehicle  and  the  HET  (Heavy  Equipment  Transporter).  A  prototype  embedded 
prognostic  system  (Real-time  Engine  Diagnostics-Prognostics,  REDI-PRO)  using 
artificial  neural  networks  has  been  developed  for  the  AGT-1500  gas  turbine 
engine  that  drives  the  M1A2  main  battle  tank.  Future  combat  systems  such  as 
the  Comanche  scout  helicopter  and  the  Crusader  self-propelled  howitzer  were 
also  being  developed  with  built  in  diagnostic  systems,  prior  to  the  termination  of 
their  programs  in  May  of  2004  and  2002,  respectively. 

The  Army  Aviation  and  Applied  Technology  Directorate  (AATD)  have  been 
involved  in  several  research  programs  that  include  diagnostics  among  their  main 
thrusts.  These  include  the  following  [2]: 

•  Future  Transport  Rotorcraft  (FTR) 

•  Joint  Turbine  Advanced  Gas  Generator  (JTAGG) 

•  Advanced  Rotorcraft  Transmission  II  (ART  II) 
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•  Rotorcraft  Drive  System  for  the  21st  Century  (RDS-21) 

•  Common  Engine  Program  (CEP) 

•  Digital  Aviation  Logistics  -  Prototype  (DAL  -  P) 

Associated  with  CEP,  FTR  and  JTAGG  is  the  Integrated  High  Performance 
Turbine  Engine  Technology  (IHPTET)  program,  which  is  a  DOD  sponsored 
program  with  involvement  from  numerous  industry  and  government  agencies  [3]. 
A  similar  program  with  much  more  emphasis  on  prognostic  capabilities  is  the 
Versatile  Affordable  Advanced  Turbine  Engine  (VAATE)  program,  which  has  two 
seven-year  phases  that  run  through  2010  and  2017,  respectively.  The  ambitious 
research  under  this  program  includes  damage  avoidance  control,  life-extending 
control,  data-fusion  techniques  for  proactive  maintenance,  turbine  blade  crack 
detection  and  virtual  component  performance  tracking  [4],  NASA's  Ultra-Efficient 
Engine  Technology  (UEET)  research  is  in  collaboration  with  the  DOD  IHPTET 
and  VAATE  programs  and  is  making  contributions  in  the  area  of  wireless  relay  of 
health  monitoring  data  to  ground  stations  and  advanced  sensing  technologies  [5], 

The  high-profile  F-35  Joint  Strike  Fighter  (JSF)  is  being  designed  with 
comprehensive  prognostics  and  health  management  (PHM)  systems.  The 
importance  of  designing  the  entire  PHM  (both  on-board  and  off-board)  in 
cooperation  with  the  initial  design  and  development  was  realized  through  past 
failures  (in  regards  to  the  lack  of  consideration  for  diagnostics  during  the  initial 
system  design)  with  numerous  military  aircraft.  While  aircraft  such  as  the  AV-8B, 
F/A-18,  T-45,  E2  and  F-14  had  some  diagnostics  designed  during  development, 
the  lack  of  a  suitable  off-board  data  management  infrastructure  meant  that  data 
analysis  and  the  development  of  robust  diagnostic  techniques  became  practically 
unachievable.  Due  to  inadequate  comparisons  of  limited  archived  data,  little 
confidence  was  placed  in  such  systems  [6].  Unlike  its  predecessors,  the  JSF 
development  process  includes  a  comprehensive  PHM-integrated  ground  station 
and  logistical  supply  system  known  as  the  Autonomic  Logistics  System  [7],  Such 
a  system  will  allow  for  component  usage  and  maintenance  action  tracking  and 
comparisons  across  the  squadron  and  fleet  levels.  The  JSF  program  is  the  most 
recent  application  of  PHM  technology,  and  will  be  the  most  advanced  system  of 
its  kind.  Every  component  that  warrants  prognostics,  based  on  safety 
requirements  and  cost  benefit  analyses,  will  be  covered  by  the  system.  The 
goals  of  the  JSF  PHM,  as  specified  by  the  Navy,  is  the  reduction  of  life  cycle 
costs  and  maintenance  man  hours  per  flight  [6],  but  also  includes  the  streamlined 
integration  of  maintenance  logistics  to  the  operational  environment  [8], 

The  V- 22  Osprey  program  is  another  high  profile  platform  that  is  being  designed 
with  diagnostics  and  prognostics  in  mind.  The  V- 22  Vibration  Structural  Life  and 
Engine  Diagnostics  (VSLED)  system  has  already  demonstrated  the  ability  to 
consistently  identify  hanger  bearing  faults  and  aided  in  the  troubleshooting  of 
excessive  nacelle  vibration.  An  engine  diagnostic  system  is  currently  in 
development  with  plans  to  monitor  the  entire  transmission  system  [9], 
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The  application  of  diagnostics  to  rotorcraft  systems  is  not  a  recent  development. 
The  first  rotorcraft  Health  and  Usage  Monitoring  Systems  (HUMS)  were 
developed  to  improve  safety  and  reliability  of  rotorcraft  operating  in  the  North 
Sea,  transporting  offshore  oil  rig  workers  to  and  from  station.  The  typical 
implementations  of  these  systems  include  drive-train  vibration  diagnostics,  oil 
particulate  monitoring  and  main  rotor  track  and  balancing.  The  first  HUMS, 
manufactured  by  Stewart  Hughes  (now  owned  by  Smiths  Industries),  was  flown 
in  1991,  and  the  Civil  Aviation  Authority  developed  the  first  helicopter  health 
monitoring  certification  standards  in  May  1999  (CAP  693,  CAA  AAD  001-05-99). 
In  the  United  States,  the  FAA  has  also  published  Advisory  Circulars  on  HUMS 
(27-1  and  29-2).  HUMS  data  analyzed  by  the  United  Kingdom  Civil  Aviation 
Authority  in  1999  revealed  that  approximately  70%  of  then-recent  airworthiness 
related  incidents  that  resulted  in  significant  maintenance  actions  (of  which  there 
were  63)  were  detected.  The  results  of  the  study  indicated  that  1  or  possibly  2  of 
the  successfully  detected  incidents  would  likely  have  resulted  in  an  in-flight 
accident  that  would  have  endangered  the  lives  of  the  crew  and  passengers.  In 
its  final  report,  the  CAA  commented  [10]: 

It  is  considered  that  the  first  generation  HUMS,  which  added 
comprehensive  vibration  monitoring  to  existing  health 
monitoring  techniques,  has  already  demonstrated  the  ability 
to  identify  potentially  hazardous  and  catastrophic  failure 
modes,  and  has  already  reduced  fatal  accident  statistics. 

The  benefits  of  HUMS  go  far  beyond  the  safety  concerns  that  predicated  its 
development.  The  reductions  in  operator  insurance  costs,  increased  availability 
due  to  less  unscheduled  maintenance,  and  increased  consumer  confidence  as  a 
reliable  mode  of  transportation  are  some  of  the  potential  secondary  benefits  of 
HUMS  [10], 

There  are  currently  three  HUMS  manufacturers,  Smiths  Industries  (Teledyne 
Controls),  BF  Goodrich,  and  the  Intelligent  Automation  Corporation.  Smiths 
Industries  has  the  longest  experience,  with  several  fielded  models:  EuroHUMS, 
North  Sea  HUMS,  AHUMS  and  GenHUMS.  The  capabilities  of  the  Smiths 
HUMS  include  vibration  monitoring  of  the  transmission  and  engines,  rotor  track 
and  balancing,  oil  particulate  monitoring,  and  integration  with  the  flight  data 
recorder.  The  use  of  these  systems  have  resulted  in  26  detections  of 
transmission  related  problems  to  date,  including  bearing  faults  (brinelled 
raceways,  damaged  rolling  elements  and  raceways),  shaft  faults  (misalignment, 
unbalance,  couplings),  and  gear  faults  (wear,  fatigue,  and  misalignment).  Their 
signal  processing  methods  include  time-synchronous  averaging,  amplitude 
demodulation  and  feature-based  techniques  for  vibration-based  gear  diagnostics; 
oil  monitoring  (chip  detection,  pressure,  temperature);  and  shock  pulse  methods 
and  pattern  recognition  techniques  for  vibration-based  bearing  diagnostics. 
Smiths  HUMS  are  installed  in  over  250  aircraft  worldwide,  and  include 
Eurocopter,  Augusta-Westland  and  Bell  Helicopter  systems.  Fielded  systems 
include  the  following  rotorcraft  models:  S61N,  AS332  (Mk1,2),  AS  532  (Mk1,2), 
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S76,  Bell  412,  BA  609,  EH101,  UK  Mod  Chinooks,  Apaches,  Sea  King,  Puma 
and  Lynx  [11], 

In  the  United  States,  the  BF  Goodrich  Corporation  won  a  1997  DARPA 
sponsored  contract  to  develop  an  Integrated  Mechanical  Diagnostic  Health  and 
Usage  Monitoring  System  (IMD-HUMS)  for  the  US  Navy.  Goodrich  has  HUMS 
systems  installed  on  US  Navy  and  Marine  Corps  V- 22,  CH-53E,  MH-53E,  SH- 
60B,  MH-60S/R,  AH-1Z  and  UH-1Y  aircraft.  In  addition,  30  systems  are  in 
delivery  to  the  US  Army  Aviation  Applied  Technology  Directorate  to  be  deployed 
on  101st  Airborne  UH-60L  Black  Hawks.  Sikorsky  (United  Technologies)  also 
has  a  contract  with  BF  Goodrich  to  provide  HUMS  for  their  S-92,  S-76,  S-70  and 
S-80  aircraft  [9]. 

The  US  Navy  has  been  active  in  PHM  technology  development  and  insertion  for 
several  years.  The  Navy’s  SH-60  Helicopter  Integrated  Diagnostic  System 
(HIDS)  was  their  initial  program  that  drove  subsequent  efforts,  including  the  DoD 
sponsored  Joint  Advanced  Health  and  Usage  Monitoring  System  Advanced 
Concept  Technology  Demonstration  (JAHUMS-ACTD).  The  JAHUMS  program 
served  to  demonstrate  the  HUMS  capabilities  within  an  operational  environment. 
Most  of  the  flight  testing  (which  began  in  early  1995),  technology  development, 
and  data  collection  were  conducted  at  the  Naval  Air  Warfare  Center  Aircraft 
Division  (NAWCAD),  Patuxent  River.  As  part  of  the  HIDS  program,  seeded  fault 
testing  of  helicopter  transmission  components  was  conducted  on  a  ground  test 
rig  to  target  flight  critical  components.  The  seeded  fault  testing  allows  data  to  be 
collected  over  the  transition  to  failure.  The  collected  data  can  then  be  used  to 
develop  diagnostic  and  prognostic  algorithms. 

At  the  same  time  that  the  Navy  was  conducting  its  JAHUMS  program,  the  Army 
and  NASA  were  involved  in  HUMS  research  for  the  UH-60A  using  the  Rotorcraft 
Aircrew  Systems  Concept  Airborne  Laboratory  (RSCAL)  This  testing  was 
accomplished  in  2001  [12], [13],  More  recently,  the  Intelligent  Automation 
Corporation  (IAC)  has  developed  a  HUMS  solution  for  the  Army  that  involves 
pilot-driven  data  acquisition  of  in-flight  vibration  that  is  collected  and  processed 
on  a  ground  station  database.  The  IAC  system  was  accepted  by  the  US  Army 
for  the  Vibration  Monitoring  Enhancement  Program  (VMEP).  The  VMEP  system 
is  fielded  on  115  units,  including  the  AH-64A/D,  UH-60A/L,  MH-60K  and  CH-47D. 
As  many  as  24  accelerometer  channels  (6  simultaneous)  and  8  tachometer 
channels  (2  simultaneous)  can  be  connected  to  the  VMEP  system,  which  is 
based  on  a  PC-104  platform  and  a  233MHz  processor.  The  AH-64  Apache  and 
UH-60  Blackhawk  are  outfitted  with  18  accelerometers,  2/3  tachometers  and  a 
blade  tracking  sensor.  The  on-board  data  acquisition  device  is  shown  in  Figure 
8.3. 
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Figure  8.3  VMEP  Vibration  Monitoring  Unit  -  Data  Acquisition  Device 
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